From mvyskocil at suse.cz Fri Apr 1 00:22:34 2011 From: mvyskocil at suse.cz (Michal Vyskocil) Date: Fri, 1 Apr 2011 09:22:34 +0200 Subject: Desktop API require gnome 2 Message-ID: <20110401072233.GB9762@zelva.suse.cz> Hi all, I got a bug about not-working java.awt.Desktop API under KDE. It seems that's already known issue [1][2]. Even if I can understand Oracle devs are interested in GNOME support only, the code of src/solaris/native/sun/xawt/awt_Desktop.c [3] dlopens libgnome-2.0 and libgnomevfs-2.0. So after installation of both libraries, Desktop API started to work. My GNOME colleagues have informed me those libs are deprecated for a long time (at least for dealing with a mime-types) and when Gnome 3 will be released, they will probably dissapear after some time - this is the case of openSUSE, but I'm sure Fedora will drop it at least at the same time, maybe earlier. This change will left Java applications without java.awt.Desktop API support. For my POw the easiest way how to fix that in portable way for unixes is patch XDesktopPeer.java to call xdg-open/xdg-email like this public void mail(URI uri) throws IOException { Runtime.exec("/usr/bin/xdg-email " + uri.toString()); } Or alternativelly if there are some usable routines in glib, they can be used as well, because in most of modern distributions Qt is build with glib main-loop support, so this library is installed everytime. And there are not known plans to increase the so number afaik. Any ideas? [1] http://stackoverflow.com/questions/102325/not-supported-platforms-for-java-awt-desktop-getdesktop [2] http://java-hamster.blogspot.com/2007/06/troubles-with-javaawtdesktop-browse.html [3] http://hg.openjdk.java.net/jdk6/jdk6/jdk/file/ba66ade54c26/src/solaris/native/sun/xawt/awt_Desktop.c Regards Michal Vyskocil From ptisnovs at redhat.com Fri Apr 1 00:43:49 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 01 Apr 2011 09:43:49 +0200 Subject: Reviewer needed: RegularFileObject patch for IcedTea6-1.10 [was Re: Reviewer needed: fix for class RegularFileObject + added new regression test] In-Reply-To: <20110331170315.GZ6143@rivendell.middle-earth.co.uk> References: <4D90A80F.7040602@redhat.com> <20110328173450.GC6143@rivendell.middle-earth.co.uk> <4D91A835.2050707@redhat.com> <20110329124009.GL6143@rivendell.middle-earth.co.uk> <4D91F3DA.2060009@redhat.com> <4D921012.8010801@redhat.com> <20110330164134.GO6143@rivendell.middle-earth.co.uk> <4D9448BA.1070608@redhat.com> <20110331144825.GV6143@rivendell.middle-earth.co.uk> <4D94A0BC.1030603@redhat.com> <20110331170315.GZ6143@rivendell.middle-earth.co.uk> Message-ID: <4D958235.7010003@redhat.com> Dr Andrew John Hughes wrote: > On 17:41 Thu 31 Mar , Pavel Tisnovsky wrote: >> Dr Andrew John Hughes wrote: >>> On 11:26 Thu 31 Mar , Pavel Tisnovsky wrote: >>> >>> It needs a NEWS entry. Something like: >>> >> Hi Andrew, >> >> new hg diff containing new NEWS entry is stored in attachment. Can you >> please review it? >> >> Pavel > > I don't see a NEWS change. This looks like the exact same patch. > Oh sorry, I copied the diff from wrong directory. It's time to tidy the disk ;-) I hope the new hg diff is correct. Pavel -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hg_diff Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110401/5d7b95c5/hg_diff.ksh From ptisnovs at redhat.com Fri Apr 1 01:23:52 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 01 Apr 2011 10:23:52 +0200 Subject: /hg/icedtea6: S7032388, PR682: Make HotSpot work on machines wit... In-Reply-To: <4D94962A.5000604@ubuntu.com> References: <4D94962A.5000604@ubuntu.com> Message-ID: <4D958B98.9080101@redhat.com> Matthias Klose wrote: > On 31.03.2011 16:34, andrew at icedtea.classpath.org wrote: >> changeset 64437a39a9c8 in /hg/icedtea6 >> details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=64437a39a9c8 >> author: Andrew John Hughes >> date: Thu Mar 31 15:34:49 2011 +0100 >> >> S7032388, PR682: Make HotSpot work on machines without cmov >> instruction again >> >> 2011-03-31 Andrew John Hughes >> >> S7032388, PR682: Make HotSpot work on machines without >> cmov instruction again >> * Makefile.am: Add new patch. >> * NEWS: Mention patch. >> * patches/hotspot/hs20/7032388-work_without_cmov_instruction.patch, >> * patches/hotspot/original/7032388-work_without_cmov_instruction.patch >> : Versions of patch for each HotSpot version. > > does this have a performance impact? It depends ;-) If this patch only replaces CMOV instruction by a conditional jump (over regular MOV), it could be faster on some processors and faster on older ones: http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus From mvyskocil at suse.cz Fri Apr 1 01:27:21 2011 From: mvyskocil at suse.cz (Michal Vyskocil) Date: Fri, 1 Apr 2011 10:27:21 +0200 Subject: [1.10] RFC: Fix HotSpot regression that prevents use on x86 processors without cmov In-Reply-To: <20110331233055.GB6315@rivendell.middle-earth.co.uk> References: <20110331231355.GA6315@rivendell.middle-earth.co.uk> <20110331231803.GI441@redhat.com> <20110331233055.GB6315@rivendell.middle-earth.co.uk> Message-ID: <20110401082720.GB28173@zelva.suse.cz> On Fri, Apr 01, 2011 at 12:30:55AM +0100, Dr Andrew John Hughes wrote: > On 19:18 Thu 31 Mar , Deepak Bhole wrote: > > * Dr Andrew John Hughes [2011-03-31 19:15]: > > > This is my last patch for 1.10. > > > > > > This issue is discussed on the bug report: > > > > > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 > > > > > > and on the HotSpot list: > > > > > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2011-March/004006.html > > > > > > The discussion on the HotSpot list came to the conclusion that > > > this is a regression from hs18 onwards and twisti has since provided > > > a fix. This fix is already in HEAD and I've seen no negative build bot > > > reports. > > > > > > The fix provides an alternative for cmov on x86 processors which lack this > > > instruction, causing them to be usable again rather than crashing on even > > > a 'java -version' invocation. > > > > > > Patches for both hs19 and hs20 are included. The only difference between > > > the two is that hs19 doesn't need the #include directions as it still has > > > IncludeDB. They are otherwise identical. > > > > > > Ok for 1.10? > > > > > > > Yes, this looks fine to me. Okay for commit. > > > > Cheers, > > Deepak > > > > Thanks! Done. Thanks a lot Andrew! Regards Michal Vyskocil -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 198 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110401/8066cf2f/attachment.bin From gbenson at redhat.com Fri Apr 1 02:28:46 2011 From: gbenson at redhat.com (Gary Benson) Date: Fri, 1 Apr 2011 10:28:46 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110331182441.GD6143@rivendell.middle-earth.co.uk> References: <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110331092125.GA3884@redhat.com> <20110331172645.GE3884@redhat.com> <20110331182441.GD6143@rivendell.middle-earth.co.uk> Message-ID: <20110401092846.GA4281@redhat.com> Dr Andrew John Hughes wrote: > On 19:20 Thu 31 Mar , Dr Andrew John Hughes wrote: > > Errr... what ARM interpreter rewrite? http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/004957.html > Sorry for the top-post; stupid broken Gmail client... Didn't realise > I had this mail in my RH inbox too. http://www.gnu.org/philosophy/javascript-trap.html From gnu_andrew at member.fsf.org Fri Apr 1 02:48:59 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Fri, 1 Apr 2011 10:48:59 +0100 Subject: Review Request: Zero and Shark fixes In-Reply-To: <20110401092846.GA4281@redhat.com> References: <5EB0B9AB-4A09-432F-B9D6-102E8D1FB65C@oracle.com> <20110331092125.GA3884@redhat.com> <20110331172645.GE3884@redhat.com> <20110331182441.GD6143@rivendell.middle-earth.co.uk> <20110401092846.GA4281@redhat.com> Message-ID: On 01/04/2011, Gary Benson wrote: > Dr Andrew John Hughes wrote: >> On 19:20 Thu 31 Mar , Dr Andrew John Hughes wrote: >> > Errr... what ARM interpreter rewrite? > > http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/004957.html > Ah, I wondered if it was that. Did you add this to IcedTea yet? >> Sorry for the top-post; stupid broken Gmail client... Didn't realise >> I had this mail in my RH inbox too. > > http://www.gnu.org/philosophy/javascript-trap.html > It's turning the Javascript off that's made the top-posting worse. I'll have to move this hotspot list to my RH inbox as well as the others. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From bugzilla-daemon at icedtea.classpath.org Fri Apr 1 06:58:07 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 01 Apr 2011 13:58:07 +0000 Subject: [Bug 684] New: [regression] zero/shark fail to run the jdk jtreg tests with hs20 Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=684 Summary: [regression] zero/shark fail to run the jdk jtreg tests with hs20 Product: IcedTea Version: 6-hg Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Zero AssignedTo: unassigned at icedtea.classpath.org ReportedBy: doko at ubuntu.com seen on icedtea6, and icedtea6-1.10 on x86, x86_64, powerpc, didn't check other platforms. Passed: java/io/InputStreamReader/GrowAfterEOF.java Passed: java/io/InputStreamReader/NullCreate.java Passed: java/io/InputStreamReader/One.java Exception in thread "ReadAheadIterator1" java.util.NoSuchElementException at java.util.LinkedList.remove(LinkedList.java:805) at java.util.LinkedList.removeFirst(LinkedList.java:151) at com.sun.javatest.TRT_Iterator.nextElement(TRT_Iterator.java:176) at com.sun.javatest.TRT_Iterator.next(TRT_Iterator.java:200) at com.sun.javatest.util.ReadAheadIterator.readAhead(ReadAheadIterator.java:258) at com.sun.javatest.util.ReadAheadIterator.access$000(ReadAheadIterator.java:36) at com.sun.javatest.util.ReadAheadIterator$1.run(ReadAheadIterator.java:192) ah, we are using samevm of course doko, it probably is the last .jtr file touched jdk/JTwork/jtData/harness.trace shows: Test starting: java/io/InputStreamReader/One.java Test finished: java/io/InputStreamReader/One.java: Passed. Execution successful so a new test is not started mjw: do you think, omitting -samevm will help? doko, it might because it will start a fresh java process for each test doko, but maybe this is in the test runner framework itself? doko: mjw but it will take eons to complete all jck tests ;-) ptisnovs: so the alternative is not to run them? doko: we have to investigate why it throws this exception. To be honest I have newer seen it on my machines, but it does not mean it's not a bug in jtreg, of course ptisnovs: this is a shark build, configured with the optional hotspot doko: is this exception always thrown on the same test (ie after One.java passes) doko: ? ptisnovs: yes, my last log stops in the same location ... doko: will look at it, probably test One.java broke something in JVM ptisnovs: interesting, without -samevm, I get right at the start of the jdk tests: Passed: com/sun/awt/Translucency/WindowOpacity.java Exception in thread "ReadAheadIterator0" java.lang.IllegalStateException at com.sun.javatest.TestResult.setTestDescription(TestResult.java:1882) at com.sun.javatest.TestResultTable.getCachedResult(TestResultTable.java:2159) at com.sun.javatest.TRT_TreeNode.processFile(TRT_TreeNode.java:1045) at com.sun.javatest.TRT_TreeNode.scanIfNeeded(TRT_TreeNode.java:639) at com.sun.javatest.TRT_TreeNode.getChildCount(TRT_TreeNode.java:113) at com.sun.javatest.TRT_Iterator$PseudoFrame.nextIndex(TRT_Iterator.java:904) at com.sun.javatest.TRT_Iterator.findNext(TRT_Iterator.java:599) at com.sun.javatest.TRT_Iterator.nextElement(TRT_Iterator.java:179) at com.sun.javatest.TRT_Iterator.next(TRT_Iterator.java:200) at com.sun.javatest.util.ReadAheadIterator.readAhead(ReadAheadIterator.java:258) at com.sun.javatest.util.ReadAheadIterator.access$000(ReadAheadIterator.java:36) at com.sun.javatest.util.ReadAheadIterator$1.run(ReadAheadIterator.java:192) Passed: com/sun/crypto/provider/Cipher/AES/Test4511676.java strange again, new hotspot only doko: may I use this HS on i686/x86_64? ptisnovs: what do you mean? it works as pure hotspot. doko: you wrote: "configured with the optional hotspot" ptisnovs: --with-hotspot-build=hs20 --enable-shark doko: ah great, will try it -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From omajid at redhat.com Fri Apr 1 07:59:22 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 01 Apr 2011 10:59:22 -0400 Subject: [icedtea-web 1.0] RFC: backport fix for RH677772: NoSuchAlgorithmException using SSL/TLS in javaws Message-ID: <4D95E84A.9070103@redhat.com> Hi, The two attached patches are backports of the fix for RH677772 in HEAD. I would like to apply the fix to the 1.0 branch too. Does anyone have any issues or concerns? Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-web-1.0-rh677772-01.patch Type: text/x-patch Size: 6088 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110401/3f83a1a1/icedtea-web-1.0-rh677772-01.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-web-1.0-rh677772-02.patch Type: text/x-patch Size: 1057 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110401/3f83a1a1/icedtea-web-1.0-rh677772-02.patch From dbhole at redhat.com Fri Apr 1 08:04:57 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 1 Apr 2011 11:04:57 -0400 Subject: [icedtea-web 1.0] RFC: backport fix for RH677772: NoSuchAlgorithmException using SSL/TLS in javaws In-Reply-To: <4D95E84A.9070103@redhat.com> References: <4D95E84A.9070103@redhat.com> Message-ID: <20110401150456.GB8142@redhat.com> * Omair Majid [2011-04-01 11:00]: > Hi, > > The two attached patches are backports of the fix for RH677772 in > HEAD. I would like to apply the fix to the 1.0 branch too. Does > anyone have any issues or concerns? > I don't have any issues. Please go ahead and commit. Cheers, Deepak > Cheers, > Omair > diff -r 04a9055a491d ChangeLog > --- a/ChangeLog Tue Mar 29 15:14:13 2011 +0100 > +++ b/ChangeLog Fri Apr 01 10:49:40 2011 -0400 > @@ -1,3 +1,18 @@ > +2011-02-23 Omair Majid > + > + RH677772: NoSuchAlgorithmException using SSL/TLS in javaws > + * NEWS: Update with bugfix. > + * netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java: Add new field > + jreExtDir. > + (JNLPPolicy): Initialize jreExtDir. > + (getPermissions): Grant AllPermissions if the CodeSourse is a system jar. > + (isSystemJar): New method. > + * netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java > + (checkPermission): Remove special casing of > + SecurityPermission("putProviderProperty.SunJCE") and > + SecurityPermission("accessClassInPackage.sun.security.internal.spec"). > + (inTrustedCallChain): Remove. > + > 2010-03-29 Andrew John Hughes > > * NEWS: Updated. > diff -r 04a9055a491d NEWS > --- a/NEWS Tue Mar 29 15:14:13 2011 +0100 > +++ b/NEWS Fri Apr 01 10:49:40 2011 -0400 > @@ -11,6 +11,7 @@ > New in release 1.0.2 (2011-XX-XX): > * Common Fixes and Improvements > - PR638: JNLPClassLoader.loadClass(String name) can return null > + - RH677772: NoSuchAlgorithmException using SSL/TLS in javaws > * Plugin > - PR612: NetDania application ends on java.security.AccessControlException: access denied (java.util.PropertyPermission browser read) > - Replace binary PDF documentation with editable HTML version. > diff -r 04a9055a491d netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java Tue Mar 29 15:14:13 2011 +0100 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java Fri Apr 01 10:49:40 2011 -0400 > @@ -16,6 +16,7 @@ > > package net.sourceforge.jnlp.runtime; > > +import java.io.File; > import java.security.*; > import java.util.Enumeration; > > @@ -40,10 +41,15 @@ > /** the previous policy */ > private static Policy systemPolicy; > > + private final String jreExtDir; > + > protected JNLPPolicy() { > shellSource = JNLPPolicy.class.getProtectionDomain().getCodeSource(); > systemSource = Policy.class.getProtectionDomain().getCodeSource(); > systemPolicy = Policy.getPolicy(); > + > + String jre = System.getProperty("java.home"); > + jreExtDir = jre + File.separator + "lib" + File.separator + "ext"; > } > > /** > @@ -54,6 +60,10 @@ > if (source.equals(systemSource) || source.equals(shellSource)) > return getAllPermissions(); > > + if (isSystemJar(source)) { > + return getAllPermissions(); > + } > + > // if we check the SecurityDesc here then keep in mind that > // code can add properties at runtime to the ResourcesDesc! > if (JNLPRuntime.getApplication() != null) { > @@ -76,6 +86,23 @@ > return systemPolicy.getPermissions(source); > } > > + > + /** > + * Returns true if the CodeSource corresponds to a system jar. That is, > + * it's part of the JRE. > + */ > + private boolean isSystemJar(CodeSource source) { > + // anything in JRE/lib/ext is a system jar and has full permissions > + String sourceProtocol = source.getLocation().getProtocol(); > + String sourcePath = source.getLocation().getPath(); > + if (sourceProtocol.toUpperCase().equals("FILE") && > + sourcePath.startsWith(jreExtDir)) { > + return true; > + } > + > + return false; > + } > + > /** > * Refresh. > */ > diff -r 04a9055a491d netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java Tue Mar 29 15:14:13 2011 +0100 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java Fri Apr 01 10:49:40 2011 -0400 > @@ -311,27 +311,6 @@ > } > } > } > - > - } else if (perm instanceof SecurityPermission) { > - tmpPerm = perm; > - > - // JCE's initialization requires putProviderProperty permission > - if (perm.equals(new SecurityPermission("putProviderProperty.SunJCE"))) { > - if (inTrustedCallChain("com.sun.crypto.provider.SunJCE", "run")) { > - return; > - } > - } > - > - } else if (perm instanceof RuntimePermission) { > - tmpPerm = perm; > - > - // KeyGenerator's init method requires internal spec access > - if (perm.equals(new SecurityPermission("accessClassInPackage.sun.security.internal.spec"))) { > - if (inTrustedCallChain("javax.crypto.KeyGenerator", "init")) { > - return; > - } > - } > - > } else { > tmpPerm = perm; > } > @@ -356,34 +335,6 @@ > } > > /** > - * Returns weather the given class and method are in the current stack, > - * and whether or not everything upto then is trusted > - * > - * @param className The name of the class to look for in the stack > - * @param methodName The name of the method for the given class to look for in the stack > - * @return Weather or not class::method() are in the chain, and everything upto there is trusted > - */ > - private boolean inTrustedCallChain(String className, String methodName) { > - > - StackTraceElement[] stack = Thread.currentThread().getStackTrace(); > - > - for (int i = 0; i < stack.length; i++) { > - > - // Everything up to the desired class/method must be trusted > - if (!stack[i].getClass().getProtectionDomain().implies(new AllPermission())) { > - return false; > - } > - > - if (stack[i].getClassName().equals(className) && > - stack[i].getMethodName().equals(methodName)) { > - return true; > - } > - } > - > - return false; > - } > - > - /** > * Asks the user whether or not to grant permission. > * @param perm the permission to be granted > * @return true if the permission was granted, false otherwise. > diff -r 06017231b935 ChangeLog > --- a/ChangeLog Fri Apr 01 10:49:54 2011 -0400 > +++ b/ChangeLog Fri Apr 01 10:50:58 2011 -0400 > @@ -1,3 +1,8 @@ > +2011-03-01 Omair Majid > + > + * netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java (isSystemJar): Check > + for nulls. > + > 2011-02-23 Omair Majid > > RH677772: NoSuchAlgorithmException using SSL/TLS in javaws > diff -r 06017231b935 netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java Fri Apr 01 10:49:54 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java Fri Apr 01 10:50:58 2011 -0400 > @@ -92,6 +92,10 @@ > * it's part of the JRE. > */ > private boolean isSystemJar(CodeSource source) { > + if (source == null || source.getLocation() == null) { > + return false; > + } > + > // anything in JRE/lib/ext is a system jar and has full permissions > String sourceProtocol = source.getLocation().getProtocol(); > String sourcePath = source.getLocation().getPath(); From dbhole at redhat.com Fri Apr 1 08:24:20 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 1 Apr 2011 11:24:20 -0400 Subject: [RFC][plugin]: class in CWD can block applet from loading. In-Reply-To: <413523174.1578371.1301430184117.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110329185749.GB27761@redhat.com> <413523174.1578371.1301430184117.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110401152419.GC8142@redhat.com> * Denis Lila [2011-03-29 16:23]: > Is this ok? > > +2011-03-29 Denis Lila > + > + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java > + (loadClass): Look through our classes before trying > + the system class loader. > > In this version I catch and ignore SecurityExceptions after > calling findClass(name). This way, if we don't have permissions > to load a class from the codebase we look through the system > classloader, which is what we do now. > This patch will not handle cases where the class is in a nested jar and in cwd, as nested jar lookup is done afterwards. Conversely, moving it lower won't work either because it would disable any sort of lazy loading as the first lookup would cause it to try to download everything. I see this in the file: // filter out 'bad' package names like java, javax // validPackage(name); Seems at someone thought about making some sort of exception for system classes, but didn't fully implement it. Cheers, Deepak > Regards, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-03-29 14:48]: > > > > Isn't javaws affected by the problem as well? > > > > > > I'm not sure. I'm testing it right now, but I thought > > > I should post my idea for the fix first. It seems like > > > the kind of thing with a high likelihood of someone not > > > liking it. If that were the case, I wouldn't have wanted > > > to waste time implementing it for javaws too. > > > > > > > Well, we control the classloader. So if javaws is affected as well > > (and > > it most likely will be, given the issue), it'd best to fix it in the > > classloader than faking a classpath for the system classloader. > > > > Cheers, > > Deepak > > > > > However, just looking at the code, I would say yes, javaws > > > is also affected. > > > > > > Regards, > > > Denis. > > > > > > ----- Original Message ----- > > > > * Denis Lila [2011-03-29 14:38]: > > > > > Hi. > > > ... > diff -r 3bbc4314e02c ChangeLog > --- a/ChangeLog Tue Mar 29 10:24:31 2011 -0400 > +++ b/ChangeLog Tue Mar 29 16:21:20 2011 -0400 > @@ -1,3 +1,9 @@ > +2011-03-29 Denis Lila > + > + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java > + (loadClass): Look through our classes before trying > + the system class loader. > + > 2011-03-29 Denis Lila > > * netx/net/sourceforge/jnlp/JNLPFile.java > diff -r 3bbc4314e02c netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Tue Mar 29 10:24:31 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Tue Mar 29 16:21:20 2011 -0400 > @@ -990,6 +990,11 @@ > // try parent classloader > if (result == null) { > try { > + return findClass(name); > + } catch (ClassNotFoundException ex) { > + } catch (SecurityException ex) { > + } > + try { > ClassLoader parent = getParent(); > if (parent == null) > parent = ClassLoader.getSystemClassLoader(); From dbhole at icedtea.classpath.org Fri Apr 1 08:37:56 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Fri, 01 Apr 2011 15:37:56 +0000 Subject: /hg/release/icedtea6-1.10: S7031385, PR680: Incorrect register a... Message-ID: changeset aafbc0658df1 in /hg/release/icedtea6-1.10 details: http://icedtea.classpath.org/hg/release/icedtea6-1.10?cmd=changeset;node=aafbc0658df1 author: Deepak Bhole date: Fri Apr 01 11:37:40 2011 -0400 S7031385, PR680: Incorrect register allocation in orderAccess_linux_x86.inline.hpp diffstat: ChangeLog | 10 +++++++ Makefile.am | 3 +- NEWS | 1 + patches/openjdk/7031385-gcc-register-allocation-fix.patch | 20 +++++++++++++++ 4 files changed, 33 insertions(+), 1 deletions(-) diffs (66 lines): diff -r e63694eb18ec -r aafbc0658df1 ChangeLog --- a/ChangeLog Fri Apr 01 00:30:31 2011 +0100 +++ b/ChangeLog Fri Apr 01 11:37:40 2011 -0400 @@ -1,3 +1,13 @@ +2011-04-01 Deepak Bhole + + S7031385, PR680: Incorrect register allocation in + orderAccess_linux_x86.inline.hpp + * Makefile.am: Apply patch. + * NEWS: Updated + * patches/openjdk/7031385-gcc-register-allocation-fix.patch: New patch. + Fixes register allocation by constraining output to one of a/b/c/d + registers. + 2011-03-31 Andrew John Hughes S7032388, PR682: Make HotSpot work on machines without diff -r e63694eb18ec -r aafbc0658df1 Makefile.am --- a/Makefile.am Fri Apr 01 00:30:31 2011 +0100 +++ b/Makefile.am Fri Apr 01 11:37:40 2011 -0400 @@ -328,7 +328,8 @@ patches/openjdk/7027667-AAShapePipeRegTest.patch \ patches/g356743-libpng-1.5.patch \ patches/mark_sun_toolkit_privileged_code.patch \ - patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch + patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ + patches/openjdk/7031385-gcc-register-allocation-fix.patch if WITH_ALT_HSBUILD ICEDTEA_PATCHES += \ diff -r e63694eb18ec -r aafbc0658df1 NEWS --- a/NEWS Fri Apr 01 00:30:31 2011 +0100 +++ b/NEWS Fri Apr 01 11:37:40 2011 -0400 @@ -18,6 +18,7 @@ - S7032388, PR682: Make HotSpot work on machines without cmov instruction again * Fixes - G356743: Support libpng 1.5. + - S7031385, PR680: Incorrect register allocation in orderAccess_linux_x86.inline.hpp * CACAO - Ignore all unknown options, but report them. - Fixes build for newer gcc (at least 4.4) on PPC64, breaks older gcc. diff -r e63694eb18ec -r aafbc0658df1 patches/openjdk/7031385-gcc-register-allocation-fix.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/openjdk/7031385-gcc-register-allocation-fix.patch Fri Apr 01 11:37:40 2011 -0400 @@ -0,0 +1,21 @@ +diff -ur openjdk.orig/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp openjdk/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp +--- openjdk.orig/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp 2011-03-31 13:05:19.924400634 -0400 ++++ openjdk/hotspot/src/os_cpu/linux_x86/vm/orderAccess_linux_x86.inline.hpp 2011-03-31 13:06:00.617400605 -0400 +@@ -86,7 +86,7 @@ + + inline void OrderAccess::store_fence(jbyte* p, jbyte v) { + __asm__ volatile ( "xchgb (%2),%0" +- : "=r" (v) ++ : "=q" (v) + : "0" (v), "r" (p) + : "memory"); + } +@@ -148,7 +148,7 @@ + // Must duplicate definitions instead of calling store_fence because we don't want to cast away volatile. + inline void OrderAccess::release_store_fence(volatile jbyte* p, jbyte v) { + __asm__ volatile ( "xchgb (%2),%0" +- : "=r" (v) ++ : "=q" (v) + : "0" (v), "r" (p) + : "memory"); + } From dlila at redhat.com Fri Apr 1 13:01:10 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 1 Apr 2011 16:01:10 -0400 (EDT) Subject: [RFC][plugin]: PluginDebug regression fix. In-Reply-To: <1418706433.1758542.1301687976672.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <2091789548.1758577.1301688070227.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. Sorry about this regression. This fixes it by printing " NULL " for null, and it also prints everything at once, for better performance and to avoid intermingled output. ChangeLog: +2011-04-01 Denis Lila + + * plugin/icedteanp/java/sun/applet/PluginDebug.java: + (toString(Object)): New function. + (debug): Check for null; print each message on its own line; + print the whole message in one call. + Regards, Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: PluginDebugRegressionFix.patch Type: text/x-patch Size: 1332 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110401/b879c9d6/PluginDebugRegressionFix.patch From dlila at redhat.com Fri Apr 1 13:31:44 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 1 Apr 2011 16:31:44 -0400 (EDT) Subject: [RFC][plugin]: PluginDebug regression fix. In-Reply-To: <2091789548.1758577.1301688070227.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <601741335.1759032.1301689904597.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Better version. Regards, Denis. ----- Original Message ----- > Hi. > > Sorry about this regression. > This fixes it by printing " NULL " for null, and > it also prints everything at once, for better > performance and to avoid intermingled output. > > ChangeLog: > +2011-04-01 Denis Lila > + > + * plugin/icedteanp/java/sun/applet/PluginDebug.java: > + (toString(Object)): New function. > + (debug): Check for null; print each message on its own line; > + print the whole message in one call. > + > > Regards, > Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: PluginDebugRegressionFix.patch Type: text/x-patch Size: 1036 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110401/27bd5861/PluginDebugRegressionFix.patch From dlila at icedtea.classpath.org Fri Apr 1 13:57:18 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Fri, 01 Apr 2011 20:57:18 +0000 Subject: /hg/icedtea-web: Fix PluginDebug regression. Message-ID: changeset 30276d468815 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=30276d468815 author: dlila date: Fri Apr 01 12:57:18 2011 -0400 Fix PluginDebug regression. diffstat: ChangeLog | 5 +++++ plugin/icedteanp/java/sun/applet/PluginDebug.java | 7 ++++++- 2 files changed, 11 insertions(+), 1 deletions(-) diffs (31 lines): diff -r 1d604ccd9b6b -r 30276d468815 ChangeLog --- a/ChangeLog Thu Mar 31 18:19:31 2011 -0400 +++ b/ChangeLog Fri Apr 01 12:57:18 2011 -0400 @@ -1,3 +1,8 @@ +2011-04-01 Denis Lila + + * plugin/icedteanp/java/sun/applet/PluginDebug.java: + (debug): Use StringBuilder to build the string. + 2011-03-31 Omair Majid * netx/net/sourceforge/jnlp/Launcher.java: Add parserSettings and extra. diff -r 1d604ccd9b6b -r 30276d468815 plugin/icedteanp/java/sun/applet/PluginDebug.java --- a/plugin/icedteanp/java/sun/applet/PluginDebug.java Thu Mar 31 18:19:31 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginDebug.java Fri Apr 01 12:57:18 2011 -0400 @@ -43,9 +43,14 @@ public static void debug(Object... messageChunks) { if (DEBUG) { + if (messageChunks == null) { + messageChunks = new Object[] {null}; + } + StringBuilder b = new StringBuilder(); for (Object chunk : messageChunks) { - System.err.println(chunk.toString()); + b.append(chunk); } + System.err.println(b.toString()); } } } From omajid at redhat.com Fri Apr 1 14:54:32 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 01 Apr 2011 17:54:32 -0400 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser In-Reply-To: <20110331205614.GI6143@rivendell.middle-earth.co.uk> References: <20110325150743.GK24061@rivendell.middle-earth.co.uk> <4D8CC78A.4080006@redhat.com> <20110330162147.GK6143@rivendell.middle-earth.co.uk> <4D93745B.9050006@redhat.com> <20110330220857.GH6143@rivendell.middle-earth.co.uk> <4D93C5ED.5000501@redhat.com> <20110331002116.GO6143@rivendell.middle-earth.co.uk> <4D94BC8E.5020301@redhat.com> <20110331182651.GE6143@rivendell.middle-earth.co.uk> <4D94D654.3020306@redhat.com> <20110331205614.GI6143@rivendell.middle-earth.co.uk> Message-ID: <4D964998.5010807@redhat.com> On 03/31/2011 04:56 PM, Dr Andrew John Hughes wrote: > On 15:30 Thu 31 Mar , Omair Majid wrote: >> On 03/31/2011 02:26 PM, Dr Andrew John Hughes wrote: >>> On 13:40 Thu 31 Mar , Omair Majid wrote: >>>> On 03/30/2011 08:21 PM, Dr Andrew John Hughes wrote: >>>>> >>>>> It does need documenting in README, but I'm happy for that to be a separate patch. >>>> >>>> Patch attached. Does that look okay? >>>> >>> >>> It's a bit brief. >>> >>> * What about documenting the --with-rhino/junit options? >>> * What about something specific about the JUnit tests? >> >> Okay, how about the new patch? >> > Still nothing on the JUnit stuff, which was the main reason I thought we were > patching the docs. The custom output and the reasoning for it should be noted > IMHO. > Ah, _now_ I get it. I thought by JUnit, you were referring to JUnit itself, not our frontend/formatter for it. I thought my documentation of that in tests/junit-runner/README was sufficient. Anyway, I have updated the README for that too. Any other suggestions? Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: update-readme-03.patch Type: text/x-patch Size: 2360 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110401/bffd365a/update-readme-03.patch From bugzilla-daemon at icedtea.classpath.org Sat Apr 2 00:06:41 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sat, 02 Apr 2011 07:06:41 +0000 Subject: [Bug 661] JDownloader crashes on start-up In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=661 Javier Kohen changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #2 from Javier Kohen 2011-04-02 07:06:41 --- I'm closing this issue because after numerous updates the issue is gone. I can't exactly tell what fixed it, I've tested this right after a couple updates of the nVidia driver and of OpenJDK to no avail, but after other seemingly unrelated system updates today it seems to work. For the record I'm answering the last questions on this thread with information from a couple weeks ago (I got to answer the questions, but never to try the open source Nouveau driver, so I never posted my answers until now). (In reply to comment #1) > (In reply to 84comment #0) > > Created an 85attachment (id=484) 86[details] [details] > > Crash dump > > > For what i know "Sun" JRE do not use opengl by default while OpenJDK do. Indeed. And when I enabled OpenGL in Sun's JRE I hit this bug, which might indicate, as you suggested, problems with the nVidia driver series 260: http://www.nvnews.net/vbulletin/showthread.php?t=156264 However, I couldn't figure out how to disable OpenGL in IcedTea. -Dsun.java2d.opengl=false didn't seem to do the trick, and -Dsun.java2d.opengl.fbobject=false also didn't help workaround the crashes. > > Yes the nvidia driver are most likely the main problem here. > > I would like you to cross check some things: > > 1) the latest 260 and later nvidia drivers have been known to execute temporal > files in /tmp/ check if /tmp are mounted with noexec and try remount > /tmp with exec and see if that solves your issue. According to mount, /tmp is mounted with the exec flag. I also verified this by running a script from that directory. > > 2) try check if you can reproduce this bug when using the xorg opengl drivers > instead of the nvidia driver. > -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 3 09:29:04 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 03 Apr 2011 16:29:04 +0000 Subject: [Bug 682] JRE on i586 machine fails to run for supports_cmov function In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #11 from Andrew John Hughes 2011-04-03 16:29:04 --- Fixed in upcoming 1.10.1 release. http://icedtea.classpath.org/hg/release/icedtea6-1.10/rev/e63694eb18ec -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 3 10:03:52 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 03 Apr 2011 17:03:52 +0000 Subject: [Bug 682] JRE on i586 machine fails to run for supports_cmov function In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=682 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |6-1.10.1 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 3 17:39:17 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 04 Apr 2011 00:39:17 +0000 Subject: [Bug 685] New: Plugin crash and data corruption Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=685 Summary: Plugin crash and data corruption Product: IcedTea Version: 6-1.9.7 Platform: all OS/Version: Linux Status: NEW Severity: major Priority: P5 Component: IcedTea6 AssignedTo: unassigned at icedtea.classpath.org ReportedBy: unfair at unfairnet.com OS: Ubuntu 10.04 LTS Browsers: Firefox 3.6.16 Opera 10.63 b6450 Linux i686, 2.6.32-30-generic Chrome 11.0.696.28 beta Using Firefox the Liveconnect functionality works properly, but in Chrome and Opera I have reproducible issues. In Chrome using Java code to raise an alert() in the browser (via JSObject's .eval() method) results in the plugin crashing 100% of the time with this error: "The following plug-in has crashed: IcedTea NPR Web Browser Plugin (using IcedTea6 1.9.7 (6b20-1.9.7-0ubuntu1~10.04.1))" Example code: HTML: Java: public void ShowAlert() { RunJS("TestAlert()"); } private void RunJS(String myJS) { try { if (myBrowser != null) { myBrowser.eval(myJS); } else { ChangeStatus("Could not retrieve browser reference!"); } } catch (Exception ex) { ChangeStatus(ex.toString()); } } Javascript: function TestAlert() { alert('test popup box'); } Using Opera there is some sort of buffer overflow/data corruption. Executing this Java function: public void Login(String UserName, String Password) { RunJS("LoginSuccess('" + UserName + "')"); } Calls this Javascript: function LoginSuccess(UserName) { setElemInner('CurrentUser',UserName.length + ":" + UserName); } function setElemInner(ElemID,ElemData) { var LElem = document.getElementById(ElemID); if (LElem != null) { LElem.innerHTML = ElemData; } } HTML: Which results in data like this: 12:TempUser??1 13:TempUserfere 12:TempUser??? 13:TempUser://nx11; -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From adalbert.prokop at gmx.de Mon Apr 4 00:53:31 2011 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Mon, 04 Apr 2011 09:53:31 +0200 Subject: Question about IcedTea6 1.9.7 + Webstart (NetX) + OSGI Message-ID: <4D9978FB.1050004@gmx.de> Hello! I've got a problem (and possibly a bug to report) with IcedTea6 1.9.7 using Webstart (NetX) and OSGI. Basically, calling BasicService.getCodeBase() always returns null if a webstart application uses OSGI. Sun/Oracle's implementation behaves differently, they return the code base as defined in the JNLP file. I suspect the problem in the JNLPSecurityManager. getApplication(Class[], int). The code iterates over all classes on the stack, retrieving their class loaders and checking their types. But in case of OSGI the method getClassLoader() will return null. I've created a small OSGI App to demostrate this problem, the Eclipse projects are attached in this mail. Is this worth a bug entry? -- Best wishes, Adalbert Prokop -------------- next part -------------- A non-text attachment was scrubbed... Name: dummy.tar.gz Type: application/gzip Size: 5000 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110404/f5299592/dummy.tar.gz From jvanek at redhat.com Mon Apr 4 04:45:15 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 04 Apr 2011 13:45:15 +0200 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser In-Reply-To: <4D964998.5010807@redhat.com> References: <20110325150743.GK24061@rivendell.middle-earth.co.uk> <4D8CC78A.4080006@redhat.com> <20110330162147.GK6143@rivendell.middle-earth.co.uk> <4D93745B.9050006@redhat.com> <20110330220857.GH6143@rivendell.middle-earth.co.uk> <4D93C5ED.5000501@redhat.com> <20110331002116.GO6143@rivendell.middle-earth.co.uk> <4D94BC8E.5020301@redhat.com> <20110331182651.GE6143@rivendell.middle-earth.co.uk> <4D94D654.3020306@redhat.com> <20110331205614.GI6143@rivendell.middle-earth.co.uk> <4D964998.5010807@redhat.com> Message-ID: <4D99AF4B.1050903@redhat.com> On 04/01/2011 11:54 PM, Omair Majid wrote: > On 03/31/2011 04:56 PM, Dr Andrew John Hughes wrote: >> On 15:30 Thu 31 Mar , Omair Majid wrote: >>> On 03/31/2011 02:26 PM, Dr Andrew John Hughes wrote: >>>> On 13:40 Thu 31 Mar , Omair Majid wrote: >>>>> On 03/30/2011 08:21 PM, Dr Andrew John Hughes wrote: >>>>>> >>>>>> It does need documenting in README, but I'm happy for that to be a >>>>>> separate patch. >>>>> >>>>> Patch attached. Does that look okay? >>>>> >>>> >>>> It's a bit brief. >>>> >>>> * What about documenting the --with-rhino/junit options? >>>> * What about something specific about the JUnit tests? >>> >>> Okay, how about the new patch? >>> >> Still nothing on the JUnit stuff, which was the main reason I thought >> we were >> patching the docs. The custom output and the reasoning for it should >> be noted >> IMHO. >> > > Ah, _now_ I get it. I thought by JUnit, you were referring to JUnit > itself, not our frontend/formatter for it. > > I thought my documentation of that in tests/junit-runner/README was > sufficient. Anyway, I have updated the README for that too. Any other > suggestions? > > Cheers, > Omair Today I have tested and walked through junit test for netx. Compraed to TestNg I consider it as big step back. I still do not see, why 3jars of easily downloadable dependences (can be handled as drops), one nicely-readable xml and annotations configuration and few lines of make.am/configure and extremely good looking and informing output and clear license was abandoned for one jar of dependence, mess makefile, nearly no configuration posibility, and custom java-class luncher (extending such a complex thing can always bring troubles and much confusion inside), maybe confusing license and its quite strange application (I'm not deep enough in it). TestNG - advantages - output, configuration(this is huge problem in JUnit), small makefile integration, license, documentation disadvantages - 2 more jars as dependencies JUnit - advantages - no dependences disadvantages - output, custom java-class luncher, no configuration, license, to much of makefile in (find *class... :-/// ) Google can be my witness;) http://www.google.com/search?q=junit+testng+comparison Basicly I do not agree with Andrews arguments against TestNG. Eg. Deepak agreed with them. Omair found them sufficient, And I'm finding them much better. Sorry for post-commit reaction but I have overlooked swap testng->junit in distro emails. Regards J. From ahughes at redhat.com Mon Apr 4 05:12:43 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 4 Apr 2011 13:12:43 +0100 Subject: 1.10 BRANCH FROZEN Message-ID: <20110404121243.GA7214@rivendell.middle-earth.co.uk> No more commits please. Release in just under two hours at 14h00 UTC. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From jvanek at redhat.com Mon Apr 4 05:57:35 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 04 Apr 2011 14:57:35 +0200 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser Message-ID: <4D99C03F.9040303@redhat.com> -------- Original Message -------- Subject: Re: [icedtea-web] RFC: add unit tests for the jnlp parser Date: Mon, 04 Apr 2011 13:45:15 +0200 From: Jiri Vanek To: distro-pkg-dev at openjdk.java.net On 04/01/2011 11:54 PM, Omair Majid wrote: > On 03/31/2011 04:56 PM, Dr Andrew John Hughes wrote: >> On 15:30 Thu 31 Mar , Omair Majid wrote: >>> On 03/31/2011 02:26 PM, Dr Andrew John Hughes wrote: >>>> On 13:40 Thu 31 Mar , Omair Majid wrote: >>>>> On 03/30/2011 08:21 PM, Dr Andrew John Hughes wrote: >>>>>> >>>>>> It does need documenting in README, but I'm happy for that to be a >>>>>> separate patch. >>>>> >>>>> Patch attached. Does that look okay? >>>>> >>>> >>>> It's a bit brief. >>>> >>>> * What about documenting the --with-rhino/junit options? >>>> * What about something specific about the JUnit tests? >>> >>> Okay, how about the new patch? >>> >> Still nothing on the JUnit stuff, which was the main reason I thought >> we were >> patching the docs. The custom output and the reasoning for it should >> be noted >> IMHO. >> > > Ah, _now_ I get it. I thought by JUnit, you were referring to JUnit > itself, not our frontend/formatter for it. > > I thought my documentation of that in tests/junit-runner/README was > sufficient. Anyway, I have updated the README for that too. Any other > suggestions? > > Cheers, > Omair Today I have tested and walked through junit test for netx. Compraed to TestNg I consider it as big step back. I still do not see, why 3jars of easily downloadable dependences (can be handled as drops), one nicely-readable xml and annotations configuration and few lines of make.am/configure and extremely good looking and informing output and clear license was abandoned for one jar of dependence, mess makefile, nearly no configuration posibility, and custom java-class luncher (extending such a complex thing can always bring troubles and much confusion inside), maybe confusing license and its quite strange application (I'm not deep enough in it). TestNG - advantages - output, configuration(this is huge problem in JUnit), small makefile integration, license, documentation disadvantages - 2 more jars as dependencies JUnit - advantages - no dependences disadvantages - output, custom java-class luncher, no configuration, license, to much of makefile in (find *class... :-/// ) Google can be my witness;) http://www.google.com/search?q=junit+testng+comparison Basicly I do not agree with Andrews arguments against TestNG. Eg. Deepak agreed with them. Omair found them sufficient, And I'm finding them much better. Sorry for post-commit reaction but I have overlooked swap testng->junit in distro emails. Regards J. From akurtakov at gmail.com Mon Apr 4 06:24:38 2011 From: akurtakov at gmail.com (akurtakov) Date: Mon, 4 Apr 2011 16:24:38 +0300 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser In-Reply-To: <4D99C03F.9040303@redhat.com> References: <4D99C03F.9040303@redhat.com> Message-ID: On Mon, Apr 4, 2011 at 3:57 PM, Jiri Vanek wrote: > > > -------- Original Message -------- > Subject: Re: [icedtea-web] RFC: add unit tests for the jnlp parser > Date: Mon, 04 Apr 2011 13:45:15 +0200 > From: Jiri Vanek > To: distro-pkg-dev at openjdk.java.net > > On 04/01/2011 11:54 PM, Omair Majid wrote: >> >> On 03/31/2011 04:56 PM, Dr Andrew John Hughes wrote: >>> >>> On 15:30 Thu 31 Mar , Omair Majid wrote: >>>> >>>> On 03/31/2011 02:26 PM, Dr Andrew John Hughes wrote: >>>>> >>>>> On 13:40 Thu 31 Mar , Omair Majid wrote: >>>>>> >>>>>> On 03/30/2011 08:21 PM, Dr Andrew John Hughes wrote: >>>>>>> >>>>>>> It does need documenting in README, but I'm happy for that to be a >>>>>>> separate patch. >>>>>> >>>>>> Patch attached. Does that look okay? >>>>>> >>>>> >>>>> It's a bit brief. >>>>> >>>>> * What about documenting the --with-rhino/junit options? >>>>> * What about something specific about the JUnit tests? >>>> >>>> Okay, how about the new patch? >>>> >>> Still nothing on the JUnit stuff, which was the main reason I thought >>> we were >>> patching the docs. The custom output and the reasoning for it should >>> be noted >>> IMHO. >>> >> >> Ah, _now_ I get it. I thought by JUnit, you were referring to JUnit >> itself, not our frontend/formatter for it. >> >> I thought my documentation of that in tests/junit-runner/README was >> sufficient. Anyway, I have updated the README for that too. Any other >> suggestions? >> >> Cheers, >> Omair > > Today I have tested and ?walked through junit test for netx. Compraed to > TestNg I consider it as big step ?back. I still do not see, why 3jars of > easily downloadable dependences Let me add a distro POV. That's the problem for distributions "easily downloadable dependencies" but most distributions do build from source and usually "easily downloadable" doesn't mean "easily buildable" . TestNG is a clasical example - it needs guice, jcommon, bsh, snakeyaml .... + all of their dependencies. This limits distros to ship older versions of such libs. E.g. in Fedora we ship testng 5.11.3 (Debian ships 5.11.x version too) with quite minimal chances for getting newer testng anytime soon. On the contra side junit is buildable with plain ant and just hamcrest as a dependency(also buildable with plain ant). If one choose to use testng he will have to limit his usage to quite old version of testng (possibly unsupported now ??) or put a bit of work in the major distros to put the needed packages in place. I agree that one can say that tests should be run by developers but if you don't run them on the bits your users will use you will lose a lot of their value. P.S. This mail is not saying anything about testng vs. junit on the technical site. It's just pointing one major point that developers(especially Java one) use to forget when considering their dependencies - keeping their dependencies in a state which won't force downstreams to hack/patch/dumb their build systems resulting in shipping software that is not build in exactly the same way upstream does. Regards, Alex > (can be handled as drops), one > nicely-readable xml and annotations configuration and few lines of > make.am/configure and extremely good looking and informing output and > clear license was abandoned ?for ?one jar of dependence, mess makefile, > nearly no ?configuration posibility, and custom java-class luncher > (extending such a complex thing can always bring troubles ?and much > confusion inside), maybe confusing license and its quite strange > application (I'm not ?deep enough in it). > > TestNG - advantages - output, configuration(this is huge problem in > JUnit), small makefile integration, license, documentation > ? ? ? ?disadvantages - 2 more jars as dependencies > JUnit - advantages - no dependences > ? ? ? ?disadvantages - output, custom java-class luncher, no configuration, > license, to much of makefile in (find *class... :-/// ) > > > > Google can be my witness;) > http://www.google.com/search?q=junit+testng+comparison > > > Basicly I do not agree with Andrews arguments against TestNG. Eg. Deepak > agreed with them. Omair found them sufficient, And I'm finding them much > better. > > > Sorry for post-commit reaction but I have overlooked swap testng->junit > in distro emails. > > > Regards J. > > From ahughes at redhat.com Mon Apr 4 08:10:06 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 4 Apr 2011 16:10:06 +0100 Subject: IcedTea6 1.10.1 Released! Message-ID: <20110404151006.GA32534@rivendell.middle-earth.co.uk> We are pleased to announce a new minor release of IcedTea6, 1.10.1! The IcedTea6 project provides a harness to build the source code from OpenJDK6 using Free Software build tools. It also includes support for using alternate virtual machines such as CACAO and JamVM. What?s New? ?????? New in release 1.10.1 (2011-04-04): * HotSpot 20 updated to b11. * Backports - S7023591, S7027667: Clipped antialiased rectangles are filled, not drawn. - Add missing privileged block around access to the sun.awt.nativedebug property. - S7032388, PR682: Make HotSpot work on machines without cmov instruction again - S7031385, PR680: Incorrect register allocation in orderAccess_linux_x86.inline.hpp * Fixes - G356743: Support libpng 1.5. * CACAO - Ignore all unknown options, but report them. - Fixes build for newer gcc (at least 4.4) on PPC64, breaks older gcc. - CA123: LD_LIBRARY_PATH and java.library.path. - CA143: don't hang with invalid locale. - CA144: aligned patchers on x86_64. - CA148: support for LCMP bytecode. - CA152: Calling Policy.setPolicy with a new Policy object has no effect on the DefaultSecurityManager. - CA156: uncaughtExceptionHandler doesn't work with OpenJDK 6 b21. - CA157: ARM SMP Assertion thinlock failed. * JamVM - Handle overflow in getPhysicalMemory(). - Base default min and max heap size on physical memory. - Fix reflective array access. - Handle O_DELETE in JVM_Open. - Minor performance improvement on ARM. - First set of changes to support JamVM/OpenJDK on MacOS X. - Minor memory leak (missing free). - Handle integer overflow on i386/amd64. - On ARM, force interpreter to be built in ARM mode. - MIPS: 64-bit and interpreter inlining by default. - Trivial implementation of stubs for MIPS. The tarball can be downloaded from: * http://icedtea.classpath.org/download/source/icedtea6-1.10.1.tar.gz SHA256 sums: 0aa25a27fc8d44aa5da65d6852e2ab5baf2e5a31470084b5c0e2dd421567d7eb icedtea6-1.10.1.tar.gz The following people helped with this release: * Deepak Bhole * Andrew John Hughes * Matthias Klose * Denis Lila * Xerxes R?nby * Pavel Tisnovsky We would also like to thank the bug reporters and testers! To get started: $ tar xzf icedtea6-1.10.1.tar.gz $ cd icedtea6-1.10.1 Full build requirements and instructions are in INSTALL: $ ./configure [--enable-cacao --enable-pulse-java --enable-systemtap ...] $ make -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at icedtea.classpath.org Mon Apr 4 08:13:52 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Mon, 04 Apr 2011 15:13:52 +0000 Subject: /hg/release/icedtea-web-1.0: 5 new changesets Message-ID: changeset a5e96f8affa6 in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=a5e96f8affa6 author: Deepak Bhole date: Sat Apr 02 17:59:32 2011 -0400 Backport patch for RH677772: NoSuchAlgorithmException using SSL/TLS in javaws changeset c16a09791e54 in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=c16a09791e54 author: Deepak Bhole date: Sat Apr 02 18:00:21 2011 -0400 Handle case where source or source.getLocation() is null when checking for system jars changeset de51c15ae614 in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=de51c15ae614 author: Deepak Bhole date: Sat Apr 02 18:04:47 2011 -0400 2011-04-04 Deepak Bhole * NEWS: Update for 1.0.2 release. * configure.ac: Bump to 1.0.2 changeset 18c14b6f3d53 in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=18c14b6f3d53 author: Deepak Bhole date: Sat Apr 02 18:05:24 2011 -0400 Added tag icedtea-web-1.0.2 for changeset de51c15ae614 changeset 9fd1cd238005 in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=9fd1cd238005 author: Deepak Bhole date: Sun Apr 03 19:11:48 2011 -0400 Prepare for 1.0.3 diffstat: .hgtags | 1 + ChangeLog | 30 ++++++++ NEWS | 5 +- configure.ac | 2 +- netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java | 31 ++++++++ netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java | 49 -------------- 6 files changed, 67 insertions(+), 51 deletions(-) diffs (203 lines): diff -r 04a9055a491d -r 9fd1cd238005 .hgtags --- a/.hgtags Tue Mar 29 15:14:13 2011 +0100 +++ b/.hgtags Sun Apr 03 19:11:48 2011 -0400 @@ -1,3 +1,4 @@ 692d7e5b31039156aff1600fd7f5034fead2f258 icedtea-web-1.0-branch 3973cfa679272d5057f2a1527483796964a1de6c icedtea-web-1.0 6af7ac54a177bf31d335ce4a58f6c7abcbd0333c icedtea-web-1.0.1 +de51c15ae614f5877373d82a8fa492325d4d6db8 icedtea-web-1.0.2 diff -r 04a9055a491d -r 9fd1cd238005 ChangeLog --- a/ChangeLog Tue Mar 29 15:14:13 2011 +0100 +++ b/ChangeLog Sun Apr 03 19:11:48 2011 -0400 @@ -1,3 +1,33 @@ +2011-04-04 Deepak Bhole + + * NEWS: Add 1.0.3 + * configure.ac: Bump to 1.0.3pre + +2011-04-04 Deepak Bhole + + * NEWS: Update for 1.0.2 release. + * configure.ac: Bump to 1.0.2 + +2011-03-01 Omair Majid + + * netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java (isSystemJar): Check + for nulls. + +2011-02-23 Omair Majid + + RH677772: NoSuchAlgorithmException using SSL/TLS in javaws + * NEWS: Update with bugfix. + * netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java: Add new field + jreExtDir. + (JNLPPolicy): Initialize jreExtDir. + (getPermissions): Grant AllPermissions if the CodeSourse is a system jar. + (isSystemJar): New method. + * netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java + (checkPermission): Remove special casing of + SecurityPermission("putProviderProperty.SunJCE") and + SecurityPermission("accessClassInPackage.sun.security.internal.spec"). + (inTrustedCallChain): Remove. + 2010-03-29 Andrew John Hughes * NEWS: Updated. diff -r 04a9055a491d -r 9fd1cd238005 NEWS --- a/NEWS Tue Mar 29 15:14:13 2011 +0100 +++ b/NEWS Sun Apr 03 19:11:48 2011 -0400 @@ -8,9 +8,12 @@ CVE-XXXX-YYYY: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=XXXX-YYYY -New in release 1.0.2 (2011-XX-XX): +New in release 1.0.3 (2011-XX-XX): + +New in release 1.0.2 (2011-04-04): * Common Fixes and Improvements - PR638: JNLPClassLoader.loadClass(String name) can return null + - RH677772: NoSuchAlgorithmException using SSL/TLS in javaws * Plugin - PR612: NetDania application ends on java.security.AccessControlException: access denied (java.util.PropertyPermission browser read) - Replace binary PDF documentation with editable HTML version. diff -r 04a9055a491d -r 9fd1cd238005 configure.ac --- a/configure.ac Tue Mar 29 15:14:13 2011 +0100 +++ b/configure.ac Sun Apr 03 19:11:48 2011 -0400 @@ -1,4 +1,4 @@ -AC_INIT([icedtea-web],[1.0.2pre],[distro-pkg-dev at openjdk.java.net], [icedtea-web], [http://icedtea.classpath.org/wiki/IcedTea-Web]) +AC_INIT([icedtea-web],[1.0.3pre],[distro-pkg-dev at openjdk.java.net], [icedtea-web], [http://icedtea.classpath.org/wiki/IcedTea-Web]) AM_INIT_AUTOMAKE([1.9 tar-pax foreign]) AC_CONFIG_FILES([Makefile]) diff -r 04a9055a491d -r 9fd1cd238005 netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java --- a/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java Tue Mar 29 15:14:13 2011 +0100 +++ b/netx/net/sourceforge/jnlp/runtime/JNLPPolicy.java Sun Apr 03 19:11:48 2011 -0400 @@ -16,6 +16,7 @@ package net.sourceforge.jnlp.runtime; +import java.io.File; import java.security.*; import java.util.Enumeration; @@ -40,10 +41,15 @@ /** the previous policy */ private static Policy systemPolicy; + private final String jreExtDir; + protected JNLPPolicy() { shellSource = JNLPPolicy.class.getProtectionDomain().getCodeSource(); systemSource = Policy.class.getProtectionDomain().getCodeSource(); systemPolicy = Policy.getPolicy(); + + String jre = System.getProperty("java.home"); + jreExtDir = jre + File.separator + "lib" + File.separator + "ext"; } /** @@ -54,6 +60,10 @@ if (source.equals(systemSource) || source.equals(shellSource)) return getAllPermissions(); + if (isSystemJar(source)) { + return getAllPermissions(); + } + // if we check the SecurityDesc here then keep in mind that // code can add properties at runtime to the ResourcesDesc! if (JNLPRuntime.getApplication() != null) { @@ -76,6 +86,27 @@ return systemPolicy.getPermissions(source); } + + /** + * Returns true if the CodeSource corresponds to a system jar. That is, + * it's part of the JRE. + */ + private boolean isSystemJar(CodeSource source) { + if (source == null || source.getLocation() == null) { + return false; + } + + // anything in JRE/lib/ext is a system jar and has full permissions + String sourceProtocol = source.getLocation().getProtocol(); + String sourcePath = source.getLocation().getPath(); + if (sourceProtocol.toUpperCase().equals("FILE") && + sourcePath.startsWith(jreExtDir)) { + return true; + } + + return false; + } + /** * Refresh. */ diff -r 04a9055a491d -r 9fd1cd238005 netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java --- a/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java Tue Mar 29 15:14:13 2011 +0100 +++ b/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java Sun Apr 03 19:11:48 2011 -0400 @@ -311,27 +311,6 @@ } } } - - } else if (perm instanceof SecurityPermission) { - tmpPerm = perm; - - // JCE's initialization requires putProviderProperty permission - if (perm.equals(new SecurityPermission("putProviderProperty.SunJCE"))) { - if (inTrustedCallChain("com.sun.crypto.provider.SunJCE", "run")) { - return; - } - } - - } else if (perm instanceof RuntimePermission) { - tmpPerm = perm; - - // KeyGenerator's init method requires internal spec access - if (perm.equals(new SecurityPermission("accessClassInPackage.sun.security.internal.spec"))) { - if (inTrustedCallChain("javax.crypto.KeyGenerator", "init")) { - return; - } - } - } else { tmpPerm = perm; } @@ -356,34 +335,6 @@ } /** - * Returns weather the given class and method are in the current stack, - * and whether or not everything upto then is trusted - * - * @param className The name of the class to look for in the stack - * @param methodName The name of the method for the given class to look for in the stack - * @return Weather or not class::method() are in the chain, and everything upto there is trusted - */ - private boolean inTrustedCallChain(String className, String methodName) { - - StackTraceElement[] stack = Thread.currentThread().getStackTrace(); - - for (int i = 0; i < stack.length; i++) { - - // Everything up to the desired class/method must be trusted - if (!stack[i].getClass().getProtectionDomain().implies(new AllPermission())) { - return false; - } - - if (stack[i].getClassName().equals(className) && - stack[i].getMethodName().equals(methodName)) { - return true; - } - } - - return false; - } - - /** * Asks the user whether or not to grant permission. * @param perm the permission to be granted * @return true if the permission was granted, false otherwise. From andrew at icedtea.classpath.org Mon Apr 4 08:16:58 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Mon, 04 Apr 2011 15:16:58 +0000 Subject: /hg/release/icedtea6-1.10: 3 new changesets Message-ID: changeset e92db53adff0 in /hg/release/icedtea6-1.10 details: http://icedtea.classpath.org/hg/release/icedtea6-1.10?cmd=changeset;node=e92db53adff0 author: Andrew John Hughes date: Mon Apr 04 15:10:52 2011 +0100 Prepare for 1.10.1 release. 2011-04-04 Andrew John Hughes * NEWS: Add date of 1.10.1 release. Move S7031385 fix to backports section. * configure.ac: Bump to 1.10.1. changeset 55870fb0e60a in /hg/release/icedtea6-1.10 details: http://icedtea.classpath.org/hg/release/icedtea6-1.10?cmd=changeset;node=55870fb0e60a author: Andrew John Hughes date: Mon Apr 04 16:11:12 2011 +0100 Added tag icedtea6-1.10.1 for changeset e92db53adff0 changeset 27de3493190b in /hg/release/icedtea6-1.10 details: http://icedtea.classpath.org/hg/release/icedtea6-1.10?cmd=changeset;node=27de3493190b author: Andrew John Hughes date: Mon Apr 04 16:16:48 2011 +0100 Prepare for 1.10.2. 2011-04-04 Andrew John Hughes * NEWS: Add 1.10.2. * configure.ac: Bump to 1.10.2pre. diffstat: .hgtags | 1 + ChangeLog | 17 ++++++++++++++--- NEWS | 6 ++++-- configure.ac | 2 +- 4 files changed, 20 insertions(+), 6 deletions(-) diffs (70 lines): diff -r aafbc0658df1 -r 27de3493190b .hgtags --- a/.hgtags Fri Apr 01 11:37:40 2011 -0400 +++ b/.hgtags Mon Apr 04 16:16:48 2011 +0100 @@ -21,3 +21,4 @@ cb463b94b82da269ea089c481ed5e39700525a8a icedtea6-1.9-branchpoint 21f2a8d158545a161ba0d997c13bdba1e6166394 icedtea6-1.10-branch 9f4eced56544b0326bb5aa011de6263ca121c7c1 icedtea6-1.10 +e92db53adff0de7449fa76bb178f96989ddddb28 icedtea6-1.10.1 diff -r aafbc0658df1 -r 27de3493190b ChangeLog --- a/ChangeLog Fri Apr 01 11:37:40 2011 -0400 +++ b/ChangeLog Mon Apr 04 16:16:48 2011 +0100 @@ -1,11 +1,22 @@ +2011-04-04 Andrew John Hughes + + * NEWS: Add 1.10.2. + * configure.ac: Bump to 1.10.2pre. + +2011-04-04 Andrew John Hughes + + * NEWS: Add date of 1.10.1 release. + Move S7031385 fix to backports section. + * configure.ac: Bump to 1.10.1. + 2011-04-01 Deepak Bhole S7031385, PR680: Incorrect register allocation in - orderAccess_linux_x86.inline.hpp + orderAccess_linux_x86.inline.hpp * Makefile.am: Apply patch. * NEWS: Updated - * patches/openjdk/7031385-gcc-register-allocation-fix.patch: New patch. - Fixes register allocation by constraining output to one of a/b/c/d + * patches/openjdk/7031385-gcc-register-allocation-fix.patch: New patch. + Fixes register allocation by constraining output to one of a/b/c/d registers. 2011-03-31 Andrew John Hughes diff -r aafbc0658df1 -r 27de3493190b NEWS --- a/NEWS Fri Apr 01 11:37:40 2011 -0400 +++ b/NEWS Mon Apr 04 16:16:48 2011 +0100 @@ -9,16 +9,18 @@ CVE-XXXX-YYYY: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=XXXX-YYYY -New in release 1.10.1 (2011-XX-XX): +New in release 1.10.2 (20XX-XX-XX): + +New in release 1.10.1 (2011-04-04): * HotSpot 20 updated to b11. * Backports - S7023591, S7027667: Clipped antialiased rectangles are filled, not drawn. - Add missing privileged block around access to the sun.awt.nativedebug property. - S7032388, PR682: Make HotSpot work on machines without cmov instruction again + - S7031385, PR680: Incorrect register allocation in orderAccess_linux_x86.inline.hpp * Fixes - G356743: Support libpng 1.5. - - S7031385, PR680: Incorrect register allocation in orderAccess_linux_x86.inline.hpp * CACAO - Ignore all unknown options, but report them. - Fixes build for newer gcc (at least 4.4) on PPC64, breaks older gcc. diff -r aafbc0658df1 -r 27de3493190b configure.ac --- a/configure.ac Fri Apr 01 11:37:40 2011 -0400 +++ b/configure.ac Mon Apr 04 16:16:48 2011 +0100 @@ -1,4 +1,4 @@ -AC_INIT([icedtea6],[1.10.1pre],[distro-pkg-dev at openjdk.java.net]) +AC_INIT([icedtea6],[1.10.2pre],[distro-pkg-dev at openjdk.java.net]) AM_INIT_AUTOMAKE([1.9 tar-pax foreign]) AC_CONFIG_FILES([Makefile]) From ahughes at redhat.com Mon Apr 4 08:17:22 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 4 Apr 2011 16:17:22 +0100 Subject: 1.10 BRANCH THAWED Message-ID: <20110404151722.GB32534@rivendell.middle-earth.co.uk> Now open for reviewed and approved commits for 1.10.2. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Mon Apr 4 08:17:46 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 4 Apr 2011 11:17:46 -0400 Subject: IcedTea-Web 1.0.2 released! Message-ID: <20110404151746.GA11160@redhat.com> IcedTea-Web 1.0.2 has been released! This is a maintenance release that contains some important bug fixes. What's new in 1.0.2: * PR638: JNLPClassLoader.loadClass(String name) can return null * RH677772: NoSuchAlgorithmException using SSL/TLS in javaws * PR612: NetDania application ends on java.security.AccessControlException: access denied (java.util.PropertyPermission browser read) * Binary PDF documentation has been replaced with an editable HTML vesion The following people helped with this release: Mark Greenwood (code), Andrew John Hughes (code), Omair Majid (code) SHA256 Checksum: aa836e4c350eaaf3a3f474522ec47069f9b71c02ce59e8dd3d79881edb15115c icedtea-web-1.0.2.tar.gz Download link: http://icedtea.classpath.org/download/source/icedtea-web-1.0.2.tar.gz After extracting (tar xzf icedtea-web-1.0.2.tar.gz), it can be built as per instructions here: http://icedtea.classpath.org/wiki/IcedTea-Web#Building_IcedTea-Web Cheers, Deepak From asu at redhat.com Mon Apr 4 09:12:31 2011 From: asu at redhat.com (Andrew Su) Date: Mon, 4 Apr 2011 12:12:31 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1909360645.366465.1301932420619.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <2103760228.367192.1301933551551.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hi, I have attached a patch for changing how cache stores its entries to fix some problems that existed in the current cache system. Right now the jar files may be overwritten by another plugin/javaws when a new version is pushed while the user is using an old version (prior update) then open another instance of the applet/javaws. With the patch this gets fixed by creating a new location for the update to be downloaded to instead of overwriting the current file. [I'm going to use applet, but assume I mean applet+javaws] Another issue with the current one is.. When loading the same applet twice (or more), it could detect that it's not current and both applet would download to the same place. In the patch, we will wait for the download to finish first then check if we have already downloaded it. If so just proceed without re-downloading. This patch makes the cache keep track of the most recently used items and remove items until we hit the cache limit if set. Changelog: 2011-04-04 Andrew Su * netx/net/sourceforge/jnlp/cache/CacheEntry.java: (markForDelete, lock, unlock): New methods. * netx/net/sourceforge/jnlp/cache/CacheUtil.java: (getCacheFile): Changed to look for most recently used item, and when not found create a new entry. (makeNewCacheFile, cleanCache, lockFile, unlockFile, lockRecentlyUsedFile, unlockRecentlyUsedFile): New methods. * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: (downloadResource): Changed to wait if we are already downloading the file. If file downloaded is compressed, mark compressed and extracted files for delete at shutdown. (initializeResource): Added checks for when the cache needs updating to create new folder entry. * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: (JNLPClassLoader): Change order so that we get resources first then check permissions for the jars. * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: (markNetxRunning): Add call to clean up cache directory. * netx/net/sourceforge/jnlp/util/FileUtils.java: (getFileLock): New method. Any questions or comments welcome. Cheers, Andrew From asu at redhat.com Mon Apr 4 09:14:41 2011 From: asu at redhat.com (Andrew Su) Date: Mon, 4 Apr 2011 12:14:41 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <2103760228.367192.1301933551551.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1228605006.367250.1301933681198.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Oops forgot to attach patch. ----- Original Message ----- > Hi, > > I have attached a patch for changing how cache stores its entries to > fix some problems that existed in the current cache system. > > Right now the jar files may be overwritten by another plugin/javaws > when a new version is pushed while the user is using an old version > (prior update) then open another instance of the applet/javaws. With > the patch this gets fixed by creating a new location for the update to > be downloaded to instead of overwriting the current file. > > [I'm going to use applet, but assume I mean applet+javaws] > Another issue with the current one is.. When loading the same applet > twice (or more), it could detect that it's not current and both applet > would download to the same place. In the patch, we will wait for the > download to finish first then check if we have already downloaded it. > If so just proceed without re-downloading. > > This patch makes the cache keep track of the most recently used items > and remove items until we hit the cache limit if set. > > Changelog: > > 2011-04-04 Andrew Su > > * netx/net/sourceforge/jnlp/cache/CacheEntry.java: > (markForDelete, lock, unlock): New methods. > * netx/net/sourceforge/jnlp/cache/CacheUtil.java: > (getCacheFile): Changed to look for most recently used item, and when > not found create a new entry. > (makeNewCacheFile, cleanCache, lockFile, unlockFile, > lockRecentlyUsedFile, unlockRecentlyUsedFile): New methods. > * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > (downloadResource): Changed to wait if we are already downloading the > file. If file downloaded is compressed, mark compressed and extracted > files for delete at shutdown. > (initializeResource): Added checks for when the cache needs updating > to create new folder entry. > * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: > (JNLPClassLoader): Change order so that we get resources first then > check permissions for the jars. > * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: > (markNetxRunning): Add call to clean up cache directory. > * netx/net/sourceforge/jnlp/util/FileUtils.java: > (getFileLock): New method. > > Any questions or comments welcome. > > Cheers, > Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110404_cache_v8.patch Type: text/x-patch Size: 27274 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110404/d43aa317/20110404_cache_v8.patch From omajid at redhat.com Mon Apr 4 10:43:03 2011 From: omajid at redhat.com (Omair Majid) Date: Mon, 04 Apr 2011 13:43:03 -0400 Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1228605006.367250.1301933681198.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1228605006.367250.1301933681198.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4D9A0327.30907@redhat.com> On 04/04/2011 12:14 PM, Andrew Su wrote: > Oops forgot to attach patch. > > ----- Original Message ----- >> > Hi, >> > >> > I have attached a patch for changing how cache stores its entries to >> > fix some problems that existed in the current cache system. >> > >> > Right now the jar files may be overwritten by another plugin/javaws >> > when a new version is pushed while the user is using an old version >> > (prior update) then open another instance of the applet/javaws. With >> > the patch this gets fixed by creating a new location for the update to >> > be downloaded to instead of overwriting the current file. >> > >> > [I'm going to use applet, but assume I mean applet+javaws] >> > Another issue with the current one is.. When loading the same applet >> > twice (or more), it could detect that it's not current and both applet >> > would download to the same place. In the patch, we will wait for the >> > download to finish first then check if we have already downloaded it. >> > If so just proceed without re-downloading. >> > >> > This patch makes the cache keep track of the most recently used items >> > and remove items until we hit the cache limit if set. >> > I think this patch would be easier to review if you split it into two patches - one to fix problems with files being overwritten, and another to enforce cache sizes. >> > Changelog: >> > >> > 2011-04-04 Andrew Su >> > >> > * netx/net/sourceforge/jnlp/cache/CacheEntry.java: >> > (markForDelete, lock, unlock): New methods. >> > * netx/net/sourceforge/jnlp/cache/CacheUtil.java: >> > (getCacheFile): Changed to look for most recently used item, and when >> > not found create a new entry. >> > (makeNewCacheFile, cleanCache, lockFile, unlockFile, >> > lockRecentlyUsedFile, unlockRecentlyUsedFile): New methods. >> > * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: >> > (downloadResource): Changed to wait if we are already downloading the >> > file. If file downloaded is compressed, mark compressed and extracted >> > files for delete at shutdown. >> > (initializeResource): Added checks for when the cache needs updating >> > to create new folder entry. >> > * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: >> > (JNLPClassLoader): Change order so that we get resources first then >> > check permissions for the jars. >> > * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: >> > (markNetxRunning): Add call to clean up cache directory. >> > * netx/net/sourceforge/jnlp/util/FileUtils.java: >> > (getFileLock): New method. >> > >> > Any questions or comments welcome. >> > I have noted some comments below. >> > Cheers, >> > Andrew > > > 20110404_cache_v8.patch > > > diff -r 30276d468815 ChangeLog > --- a/ChangeLog Fri Apr 01 12:57:18 2011 -0400 > +++ b/ChangeLog Mon Apr 04 12:13:32 2011 -0400 > @@ -1,3 +1,26 @@ > +2011-04-04 Andrew Su > + > + * netx/net/sourceforge/jnlp/cache/CacheEntry.java: > + (markForDelete, lock, unlock): New methods. > + * netx/net/sourceforge/jnlp/cache/CacheUtil.java: > + (getCacheFile): Changed to look for most recently used item, and when > + not found create a new entry. > + (makeNewCacheFile, cleanCache, lockFile, unlockFile, > + lockRecentlyUsedFile, unlockRecentlyUsedFile): New methods. > + * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > + (downloadResource): Changed to wait if we are already downloading the > + file. If file downloaded is compressed, mark compressed and extracted > + files for delete at shutdown. > + (initializeResource): Added checks for when the cache needs updating > + to create new folder entry. > + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: > + (JNLPClassLoader): Change order so that we get resources first then > + check permissions for the jars. > + * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: > + (markNetxRunning): Add call to clean up cache directory. > + * netx/net/sourceforge/jnlp/util/FileUtils.java: > + (getFileLock): New method. > + > 2011-04-01 Denis Lila > > * plugin/icedteanp/java/sun/applet/PluginDebug.java: > diff -r 30276d468815 netx/net/sourceforge/jnlp/cache/CacheEntry.java > --- a/netx/net/sourceforge/jnlp/cache/CacheEntry.java Fri Apr 01 12:57:18 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheEntry.java Mon Apr 04 12:13:32 2011 -0400 > @@ -162,4 +162,25 @@ > properties.store(); > } > > + /** > + * This adds an entry to the properties file to indicate we should delete this on exit. > + */ > + public void markForDelete() { // once marked it should not be unmarked. Not sure if this comment is meant for someone calling markForDelete, or if this is an implementation detail. > + properties.setProperty("delete", Boolean.toString(true)); > + } > + > + /** > + * This locks the properties file so only one thing can access this entry at a time. > + */ > + protected void lock() { > + CacheUtil.lockFile(properties); > + } > + > + /** > + * This unlocks the properties file. > + */ > + protected void unlock() { > + CacheUtil.unlockFile(properties); > + } > + > } > diff -r 30276d468815 netx/net/sourceforge/jnlp/cache/CacheUtil.java > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Fri Apr 01 12:57:18 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 04 12:13:32 2011 -0400 > @@ -21,6 +21,8 @@ > import java.io.*; > import java.net.*; > import java.nio.channels.FileChannel; > +import java.nio.channels.FileLock; > +import java.nio.channels.OverlappingFileLockException; > import java.util.*; > import java.security.*; > import javax.jnlp.*; > @@ -29,6 +31,7 @@ > import net.sourceforge.jnlp.config.DeploymentConfiguration; > import net.sourceforge.jnlp.runtime.*; > import net.sourceforge.jnlp.util.FileUtils; > +import net.sourceforge.jnlp.util.PropertiesFile; > > /** > * Provides static methods to interact with the cache, download > @@ -39,6 +42,15 @@ > */ > public class CacheUtil { > > + public static final String cacheDir = new File(JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)).getPath(); // Do this with file to standardize it. > + public static final String recentlyUsed = cacheDir + File.separator + "RecentlyUsed"; > + Please dont make variables that contain sensitive information (like user's home dir) public. What happens if someone accidentally uses the CacheUtil class before JNLPRuntime.initialize() is called? I think cacheDir will be null at that point. I dont understand the comment... are you referring to canonicalizing paths? getCanonicalPath() might be more appropriate. > + private static PropertiesFile cacheOrder = new PropertiesFile(new File(cacheDir + File.separator + "RecentlyUsed")); > + private static HashMap propertiesLockPool = new HashMap(); > + Perhaps these should be final? > + private static FileLock fl = null; > + private static int lockCount = 0; > + > /** > * Compares a URL using string compare of its protocol, host, > * port, path, query, and anchor. This method avoids the host > @@ -138,8 +150,7 @@ > return; > } > > - File cacheDir = new File(JNLPRuntime.getConfiguration() > - .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)); > + File cacheDir = new File(CacheUtil.cacheDir); > if (!(cacheDir.isDirectory())) { > return; > } > @@ -284,18 +295,86 @@ > if (!isCacheable(source, version)) > throw new IllegalArgumentException(R("CNotCacheable", source)); > > - try { > - String cacheDir = JNLPRuntime.getConfiguration() > - .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR); > - File localFile = urlToPath(source, cacheDir); > - FileUtils.createParentDir(localFile); > + File cacheFile = null; > + File urlPath = urlToPath(source, ""); > > - return localFile; > - } catch (Exception ex) { > - if (JNLPRuntime.isDebug()) > - ex.printStackTrace(); > + lockRecentlyUsedFile(); > + String folder = ""; > + synchronized (cacheOrder) { // We can only look for one cache file at a time. Since if we open same applet twice same plugin that causes similar problems. Please try to keep lines under 80 chars, unless there is a good reason. > + cacheOrder.load(); // Update hashtable. In complex code like this, please include comments that explain why you are doing things, not what you are doing. > + Set set = cacheOrder.keySet(); > + if (set.size()> 0) { // There are items cached, we need to look through them. > + String[] keys = set.toArray(new String[0]); > + List listKeys = Arrays.asList(keys); > + Collections.sort(listKeys); Can you please document the format of the RecentlyUsedFile? > > - return null; > + // We now want to start searching from the most recent to least recent. > + for (int i = listKeys.size() - 1; i>= 0; i--) { > + String str = cacheOrder.getProperty(listKeys.get(i)); > + if (str != null) { > + str = str.substring(cacheDir.length()); > + int index = str.indexOf(File.separatorChar, 1); > + folder = str.substring(1, index); > + str = str.substring(index); > + > + if (str.equals(urlPath.getPath())) { // We found a match. Don't know if it is old though. > + cacheFile = new File(cacheOrder.getProperty(listKeys.get(i))); > + cacheOrder.remove(listKeys.get(i)); // We can remove this since we will add it back as updated. > + break; // Stop searching since we got newest one already. > + } > + } > + } > + } > + > + if (cacheFile != null) { // We found a file above. > + // We requested it recently so mark it as recent. > + // We append folder to guarantee uniqueness. Since it might be too quick in calculations. > + cacheOrder.put(Long.toString(System.currentTimeMillis()) + folder, cacheFile.getPath()); Hm... it's not obvious to me, but what ensures that the combination "currentTimeMillis() + folder" is unique? Will this assumption hold when we have machines which are much faster? > + cacheOrder.store(); > + } else { // We did not find a copy of it. This will also add it to list. > + cacheFile = makeNewCacheFile(source, version); > + } > + } Seems to me like this method is trying to do too much. Would it be possible to move the policy (LRU) to somewhere else? I think it might be better if you have one class responsible for the actual policy. Perhaps another (class or method) for extracting and adding entires might make this code a lot clearer to read. > + unlockRecentlyUsedFile(); > + return cacheFile; > + } > + > + /** > + * This will create a new entry for the cache item. It is however > + * not initialized but any future calls to getCacheFile with the > + * source and version given to here, will cause it to return this item. > + * @param source the source URL > + * @param version the version id of the local file > + * @return the file location in the cache. > + */ > + public static File makeNewCacheFile(URL source, Version version) { > + synchronized (cacheOrder) { > + lockRecentlyUsedFile(); > + cacheOrder.load(); > + > + File cacheFile = null; > + for (long i = 0; i< Long.MAX_VALUE; i++) { > + String path = cacheDir + File.separator + i; > + File cDir = new File(path); > + if (!cDir.exists()) { What cleans up this directory? > + // We can use this directory. > + try { > + cacheFile = urlToPath(source, path); > + FileUtils.createParentDir(cacheFile); > + File pf = new File(cacheFile.getPath() + ".info"); > + FileUtils.createRestrictedFile(pf, true); // Create the info file for marking later. > + cacheOrder.setProperty(Long.toString(System.currentTimeMillis()) + i, cacheFile.getPath()); > + cacheOrder.store(); > + } catch (IOException ioe) { > + ioe.printStackTrace(); > + } > + > + break; > + } > + } > + > + unlockRecentlyUsedFile(); > + return cacheFile; > } > } > > @@ -436,4 +515,151 @@ > } > } > > + public static void cleanCache() { > + if (okToClearCache()) { > + long maxSize = -1; > + try { > + maxSize = Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); > + maxSize = maxSize * 1024 * 1024; > + } catch (NumberFormatException nfe) { > + // This is fine, we will just default to infinite cache. > + } > + long totalSize = 0; > + > + // First we want to figure out which stuff we need to delete. > + // There should not be any duplicate entries in cacheOrder, since we always clear old when setting new. > + // Thus we don't need to search through that. > + // We now go through all the entries and pick out the ones that aren't marked for delete starting from the back. > + HashSet keep = new HashSet(); > + cacheOrder.load(); > + Set set = cacheOrder.keySet(); > + String[] keys = set.toArray(new String[0]); > + List listKeys = Arrays.asList(keys); > + Collections.sort(listKeys); This code looks identical to the one above. I am qutie convinced this should be abstracted away. > + // We now want to start searching from the most recent to least recent. > + for (int i = listKeys.size() - 1; i>= 0; i--) { > + // Check if the item is contained in cacheOrder. > + String str = cacheOrder.getProperty(listKeys.get(i)); > + > + if (str != null) { > + File temp = new File(str); > + PropertiesFile pf = new PropertiesFile(new File(str + ".info")); > + boolean delete = Boolean.parseBoolean(pf.getProperty("delete")); > + > + // This will get me the root directory specific to this cache item. > + String rStr = str.substring(cacheDir.length()); > + rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1)); > + > + if (temp.isFile()&& !delete&& (maxSize< -1 || totalSize + temp.length()< maxSize)&& !keep.contains(str.substring(rStr.length()))) { // File exist, might want to keep. Please split this across multiple lines. Perhaps even better, can you write a method (with a more descriptive name) that evaulates this conditional? > + totalSize += temp.length(); > + // Since we are keeping it, we will delete any extra files extracted by JNLPClassLoader.activateJars(). > + for (File f : temp.getParentFile().listFiles()) { > + if (!f.getPath().equals(temp.getPath())&& !f.getPath().equals(pf.getStoreFile().getPath())) { > + try { > + FileUtils.recursiveDelete(f, f); > + } catch (IOException e) { > + e.printStackTrace(); > + } > + } > + } > + > + keep.add(str.substring(rStr.length())); > + keep.add(rStr); // We can just use the same map, since these two things are disjoint with each other. > + } else { > + temp = new File(rStr); > + try { > + FileUtils.recursiveDelete(temp, temp); > + } catch (IOException e) { // It's ok if we can't delete the actual directory as long as files are deleted. It would just look messy. > + e.printStackTrace(); > + } > + cacheOrder.remove(listKeys.get(i)); > + } > + } > + } > + cacheOrder.store(); > + > + // Not all items will exist in cacheOrder, thus we will need to remove them manually, but a majority of them should be removed by the above segment. > + File temp = new File(cacheDir); > + // Remove all folder not listed in keep. > + for (File f : temp.listFiles()) { > + String path = f.getPath(); > + temp = new File(path); > + if (temp.isDirectory()&& !keep.contains(temp.getPath())) { > + try { > + FileUtils.recursiveDelete(temp, temp); > + } catch (IOException e) { > + e.printStackTrace(); > + } > + } > + } Can you elaborate a little more on this? What files are we deleting here? > + } > + } > + > + /** > + * Lock the property file and add it to our pool of locks. > + * @param properties Property file to lock. > + */ > + public static void lockFile(PropertiesFile properties) { > + File storeFile = properties.getStoreFile(); > + try { > + propertiesLockPool.put(storeFile.getPath(), FileUtils.getFileLock(storeFile.getPath(), false, true)); > + } catch (OverlappingFileLockException e) { > + } catch (FileNotFoundException e) { > + e.printStackTrace(); > + } > + } > + > + /** > + * Unlock the property file and remove it from our pool. > + * Nothing happens if it wasn't locked. > + * @param properties Property file to unlock. > + */ > + public static void unlockFile(PropertiesFile properties) { > + File storeFile = properties.getStoreFile(); > + FileLock fl = propertiesLockPool.get(storeFile.getPath()); > + try { > + if (fl == null) return; > + fl.release(); > + fl.channel().close(); > + propertiesLockPool.remove(storeFile.getPath()); > + } catch (IOException e) { > + e.printStackTrace(); > + } > + } > + > + private static void lockRecentlyUsedFile() { > + synchronized (recentlyUsed) { > + try { > + File f = new File(recentlyUsed); > + if (!f.exists()) { > + FileUtils.createParentDir(f); > + FileUtils.createRestrictedFile(f, true); > + } > + fl = FileUtils.getFileLock(f.getPath(), false, true); > + lockCount++; > + } catch (OverlappingFileLockException e) { // if overlap we just increase the count. > + lockCount++; > + } catch (Exception e) { // We didn't get a lock.. > + e.printStackTrace(); > + } > + } > + } > + > + private static void unlockRecentlyUsedFile() { > + synchronized (recentlyUsed) { > + if (fl != null) { > + lockCount--; > + try { > + if (lockCount == 0) { > + fl.release(); > + fl.channel().close(); > + fl = null; > + } > + } catch (IOException e) { > + e.printStackTrace(); > + } > + } > + } > + } > + > } > diff -r 30276d468815 netx/net/sourceforge/jnlp/cache/ResourceTracker.java > --- a/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Fri Apr 01 12:57:18 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Mon Apr 04 12:13:32 2011 -0400 > @@ -630,6 +630,9 @@ > private void downloadResource(Resource resource) { > resource.fireDownloadEvent(); // fire DOWNLOADING > > + CacheEntry origEntry = new CacheEntry(resource.location, resource.downloadVersion); // This is where the jar file will be. > + origEntry.lock(); > + > try { > // create out second in case in does not exist > URL realLocation = resource.getDownloadLocation(); > @@ -666,58 +669,73 @@ > } else if (gzip) { > downloadLocation = new URL(downloadLocation.toString() + ".gz"); > } > + > + CacheEntry finalEntry = new CacheEntry(downloadLocation, resource.downloadVersion); // This is where the jar/compressed file will be. > + File downloadLocationFile = CacheUtil.getCacheFile(downloadLocation, resource.downloadVersion); > > - InputStream in = new BufferedInputStream(con.getInputStream()); > - OutputStream out = CacheUtil.getOutputStream(downloadLocation, resource.downloadVersion); > - byte buf[] = new byte[1024]; > - int rlen; > - > - while (-1 != (rlen = in.read(buf))) { > - resource.transferred += rlen; > - out.write(buf, 0, rlen); > - } > - > - in.close(); > - out.close(); > - > - // explicitly close the URLConnection. > - if (con instanceof HttpURLConnection) > - ((HttpURLConnection) con).disconnect(); > - > - /* > - * If the file was compressed, uncompress it. > - */ > - > - if (packgz) { > - GZIPInputStream gzInputStream = new GZIPInputStream(new FileInputStream( > - CacheUtil.getCacheFile(downloadLocation, resource.downloadVersion))); > - InputStream inputStream = new BufferedInputStream(gzInputStream); > - > - JarOutputStream outputStream = new JarOutputStream(new FileOutputStream( > - CacheUtil.getCacheFile(resource.location, resource.downloadVersion))); > - > - Unpacker unpacker = Pack200.newUnpacker(); > - unpacker.unpack(inputStream, outputStream); > - > - outputStream.close(); > - inputStream.close(); > - gzInputStream.close(); > - } else if (gzip) { > - GZIPInputStream gzInputStream = new GZIPInputStream(new FileInputStream(CacheUtil > - .getCacheFile(downloadLocation, resource.downloadVersion))); > - InputStream inputStream = new BufferedInputStream(gzInputStream); > - > - BufferedOutputStream outputStream = new BufferedOutputStream( > - new FileOutputStream(CacheUtil.getCacheFile(resource.location, > - resource.downloadVersion))); > - > - while (-1 != (rlen = inputStream.read(buf))) { > - outputStream.write(buf, 0, rlen); > + if (!downloadLocationFile.exists()) { How well does this interact with the download progress indicators? How are they updated? > + byte buf[] = new byte[1024]; > + int rlen; > + // Make sure we don't re-download the file. however it will wait as if it was downloading. > + // (This is fine because file is not ready yet anyways) > + InputStream in = new BufferedInputStream(con.getInputStream()); > + OutputStream out = CacheUtil.getOutputStream(downloadLocation, resource.downloadVersion); > + > + while (-1 != (rlen = in.read(buf))) { > + resource.transferred += rlen; > + out.write(buf, 0, rlen); > } > - > - outputStream.close(); > - inputStream.close(); > - gzInputStream.close(); > + > + in.close(); > + out.close(); > + > + // explicitly close the URLConnection. > + if (con instanceof HttpURLConnection) > + ((HttpURLConnection) con).disconnect(); > + > + /* > + * If the file was compressed, uncompress it. > + */ > + > + if (packgz) { > + GZIPInputStream gzInputStream = new GZIPInputStream(new FileInputStream( > + CacheUtil.getCacheFile(downloadLocation, resource.downloadVersion))); > + InputStream inputStream = new BufferedInputStream(gzInputStream); > + origEntry.markForDelete(); > + origEntry.store(); > + finalEntry.markForDelete(); > + finalEntry.store(); > + > + JarOutputStream outputStream = new JarOutputStream(new FileOutputStream( > + CacheUtil.getCacheFile(resource.location, resource.downloadVersion))); > + > + Unpacker unpacker = Pack200.newUnpacker(); > + unpacker.unpack(inputStream, outputStream); > + > + outputStream.close(); > + inputStream.close(); > + gzInputStream.close(); > + } else if (gzip) { > + GZIPInputStream gzInputStream = new GZIPInputStream(new FileInputStream(CacheUtil > + .getCacheFile(downloadLocation, resource.downloadVersion))); > + InputStream inputStream = new BufferedInputStream(gzInputStream); > + origEntry.markForDelete(); > + origEntry.store(); > + finalEntry.markForDelete(); > + finalEntry.store(); > + > + BufferedOutputStream outputStream = new BufferedOutputStream( > + new FileOutputStream(CacheUtil.getCacheFile(resource.location, > + resource.downloadVersion))); > + > + while (-1 != (rlen = inputStream.read(buf))) { > + outputStream.write(buf, 0, rlen); > + } > + > + outputStream.close(); > + inputStream.close(); > + gzInputStream.close(); > + } > } > > resource.changeStatus(DOWNLOADING, DOWNLOADED); > @@ -734,6 +752,8 @@ > lock.notifyAll(); // wake up wait's to check for completion > } > resource.fireDownloadEvent(); // fire ERROR > + } finally { > + origEntry.unlock(); > } > } > > @@ -744,6 +764,9 @@ > private void initializeResource(Resource resource) { > resource.fireDownloadEvent(); // fire CONNECTING > > + CacheEntry entry = new CacheEntry(resource.location, resource.requestVersion); > + entry.lock(); > + > try { > File localFile = CacheUtil.getCacheFile(resource.location, resource.downloadVersion); > > @@ -755,6 +778,17 @@ > > int size = connection.getContentLength(); > boolean current = CacheUtil.isCurrent(resource.location, resource.requestVersion, connection)&& resource.getUpdatePolicy() != UpdatePolicy.FORCE; > + if (!current) { > + if (entry.isCached()) { > + entry.markForDelete(); > + entry.store(); > + localFile = CacheUtil.makeNewCacheFile(resource.location, resource.downloadVersion); > + CacheEntry newEntry = new CacheEntry(resource.location, resource.requestVersion); > + newEntry.lock(); > + entry.unlock(); > + entry = newEntry; > + } > + } > > synchronized (resource) { > resource.localFile = localFile; > @@ -768,7 +802,6 @@ > } > > // update cache entry > - CacheEntry entry = new CacheEntry(resource.location, resource.requestVersion); > if (!current) > entry.initialize(connection); > > @@ -792,6 +825,8 @@ > lock.notifyAll(); // wake up wait's to check for completion > } > resource.fireDownloadEvent(); // fire ERROR > + } finally { > + entry.unlock(); > } > } > > diff -r 30276d468815 netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Fri Apr 01 12:57:18 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Mon Apr 04 12:13:32 2011 -0400 > @@ -166,11 +166,11 @@ > // initialize extensions > initializeExtensions(); > > + initializeResources(); > + > // initialize permissions > initializePermissions(); > > - initializeResources(); > - > setSecurity(); > > installShutdownHooks(); > diff -r 30276d468815 netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Fri Apr 01 12:57:18 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Mon Apr 04 12:13:32 2011 -0400 > @@ -701,6 +701,7 @@ > Runtime.getRuntime().addShutdownHook(new Thread() { > public void run() { > markNetxStopped(); > + CacheUtil.cleanCache(); > } > }); > } > diff -r 30276d468815 netx/net/sourceforge/jnlp/util/FileUtils.java > --- a/netx/net/sourceforge/jnlp/util/FileUtils.java Fri Apr 01 12:57:18 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/util/FileUtils.java Mon Apr 04 12:13:32 2011 -0400 > @@ -19,7 +19,11 @@ > import static net.sourceforge.jnlp.runtime.Translator.R; > > import java.io.File; > +import java.io.FileNotFoundException; > import java.io.IOException; > +import java.io.RandomAccessFile; > +import java.nio.channels.FileChannel; > +import java.nio.channels.FileLock; > > import net.sourceforge.jnlp.runtime.JNLPRuntime; > > @@ -292,4 +296,42 @@ > > } > > + /** > + * This will return a lock to the file specified. > + * > + * @param name Name of the file to get lock from. Is this the file name or the file path? > + * @param shared Specify if the lock will be a shared lock. > + * @param allowBlock Specify if we should block when we can not get the > + * lock. No effect when trying to get shared lock. What does no effect mean? Will it always block? > + * @return FileLock if we were successful in getting a lock, otherwise null. > + * @throws FileNotFoundException If the file does not exist. > + */ > + public static FileLock getFileLock(String name, boolean shared, boolean allowBlock) throws FileNotFoundException { > + RandomAccessFile rafFile = new RandomAccessFile(name, "rw"); > + FileChannel fc = rafFile.getChannel(); > + FileLock lock = null; > + try { > + if (!shared) { > + if (allowBlock) { > + lock = fc.lock(0, Long.MAX_VALUE, false); > + } else { > + lock = fc.tryLock(0, Long.MAX_VALUE, false); > + } > + } else { // We want shared lock. This will block regardless if allowBlock is true or not. > + // Test to see if we can get a shared lock. > + lock = fc.lock(0, 1, true); // Block if a non exclusive lock is being held. > + if (!lock.isShared()) { // This lock is an exclusive lock. Use alternate solution. > + FileLock tempLock = null; > + for (long pos = 1; tempLock == null&& pos< Long.MAX_VALUE - 1; pos++) { > + tempLock = fc.tryLock(pos, 1, false); > + } > + lock.release(); > + lock = tempLock; // Get the unique exclusive lock. > + } Since we are emulating a shared lock using exclusive locks in a number of places (I recall seeing another patch before that was doing this), can we plese implement this in a separate class and reuse that rather than implementing this in a buch of places? > + } > + } catch (IOException e) { > + e.printStackTrace(); > + } > + return lock; > + } > } Cheers, Omair From bugzilla-daemon at icedtea.classpath.org Mon Apr 4 14:22:57 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 04 Apr 2011 21:22:57 +0000 Subject: [Bug 686] New: IcedTea6 1.10 build fails on Sparc Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=686 Summary: IcedTea6 1.10 build fails on Sparc Product: IcedTea Version: 6-1.10 Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: IcedTea6 AssignedTo: unassigned at icedtea.classpath.org ReportedBy: dbhole at redhat.com IcedTea6 1.10 fails to build on Sparc architecture. The build failure log is attached. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Mon Apr 4 14:24:46 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 04 Apr 2011 21:24:46 +0000 Subject: [Bug 686] IcedTea6 1.10 build fails on Sparc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=686 --- Comment #1 from Deepak Bhole 2011-04-04 21:24:46 --- Created an attachment (id=506) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=506) IcedTea6 1.10 Sparc build log -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From asu at redhat.com Mon Apr 4 14:45:47 2011 From: asu at redhat.com (Andrew Su) Date: Mon, 4 Apr 2011 17:45:47 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <4D9A0327.30907@redhat.com> Message-ID: <415999679.375498.1301953547448.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 04/04/2011 12:14 PM, Andrew Su wrote: > > Oops forgot to attach patch. > > > > ----- Original Message ----- > >> > Hi, > >> > > >> > I have attached a patch for changing how cache stores its > >> > entries to > >> > fix some problems that existed in the current cache system. > >> > > >> > Right now the jar files may be overwritten by another > >> > plugin/javaws > >> > when a new version is pushed while the user is using an old > >> > version > >> > (prior update) then open another instance of the applet/javaws. > >> > With > >> > the patch this gets fixed by creating a new location for the > >> > update to > >> > be downloaded to instead of overwriting the current file. > >> > > >> > [I'm going to use applet, but assume I mean applet+javaws] > >> > Another issue with the current one is.. When loading the same > >> > applet > >> > twice (or more), it could detect that it's not current and both > >> > applet > >> > would download to the same place. In the patch, we will wait for > >> > the > >> > download to finish first then check if we have already > >> > downloaded it. > >> > If so just proceed without re-downloading. > >> > > >> > This patch makes the cache keep track of the most recently used > >> > items > >> > and remove items until we hit the cache limit if set. > >> > > > I think this patch would be easier to review if you split it into two > patches - one to fix problems with files being overwritten, and > another > to enforce cache sizes. I've removed the section which will ensure the cache limit. Will post that later. > > >> > Changelog: > >> > > >> > 2011-04-04 Andrew Su > >> > > >> > * netx/net/sourceforge/jnlp/cache/CacheEntry.java: > >> > (markForDelete, lock, unlock): New methods. > >> > * netx/net/sourceforge/jnlp/cache/CacheUtil.java: > >> > (getCacheFile): Changed to look for most recently used item, and > >> > when > >> > not found create a new entry. > >> > (makeNewCacheFile, cleanCache, lockFile, unlockFile, > >> > lockRecentlyUsedFile, unlockRecentlyUsedFile): New methods. > >> > * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > >> > (downloadResource): Changed to wait if we are already > >> > downloading the > >> > file. If file downloaded is compressed, mark compressed and > >> > extracted > >> > files for delete at shutdown. > >> > (initializeResource): Added checks for when the cache needs > >> > updating > >> > to create new folder entry. > >> > * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: > >> > (JNLPClassLoader): Change order so that we get resources first > >> > then > >> > check permissions for the jars. > >> > * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: > >> > (markNetxRunning): Add call to clean up cache directory. > >> > * netx/net/sourceforge/jnlp/util/FileUtils.java: > >> > (getFileLock): New method. > >> > > >> > Any questions or comments welcome. > >> > > > I have noted some comments below. > > >> > Cheers, > >> > Andrew > > > > > > 20110404_cache_v8.patch > > > > > > diff -r 30276d468815 ChangeLog > > --- a/ChangeLog Fri Apr 01 12:57:18 2011 -0400 > > +++ b/ChangeLog Mon Apr 04 12:13:32 2011 -0400 > > @@ -1,3 +1,26 @@ > > +2011-04-04 Andrew Su > > + > > + * netx/net/sourceforge/jnlp/cache/CacheEntry.java: > > + (markForDelete, lock, unlock): New methods. > > + * netx/net/sourceforge/jnlp/cache/CacheUtil.java: > > + (getCacheFile): Changed to look for most recently used item, and > > when > > + not found create a new entry. > > + (makeNewCacheFile, cleanCache, lockFile, unlockFile, > > + lockRecentlyUsedFile, unlockRecentlyUsedFile): New methods. > > + * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > > + (downloadResource): Changed to wait if we are already downloading > > the > > + file. If file downloaded is compressed, mark compressed and > > extracted > > + files for delete at shutdown. > > + (initializeResource): Added checks for when the cache needs > > updating > > + to create new folder entry. > > + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: > > + (JNLPClassLoader): Change order so that we get resources first > > then > > + check permissions for the jars. > > + * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: > > + (markNetxRunning): Add call to clean up cache directory. > > + * netx/net/sourceforge/jnlp/util/FileUtils.java: > > + (getFileLock): New method. > > + > > 2011-04-01 Denis Lila > > > > * plugin/icedteanp/java/sun/applet/PluginDebug.java: > > diff -r 30276d468815 netx/net/sourceforge/jnlp/cache/CacheEntry.java > > --- a/netx/net/sourceforge/jnlp/cache/CacheEntry.java Fri Apr 01 > > 12:57:18 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/cache/CacheEntry.java Mon Apr 04 > > 12:13:32 2011 -0400 > > @@ -162,4 +162,25 @@ > > properties.store(); > > } > > > > + /** > > + * This adds an entry to the properties file to indicate we should > > delete this on exit. > > + */ > > + public void markForDelete() { // once marked it should not be > > unmarked. > > Not sure if this comment is meant for someone calling markForDelete, > or > if this is an implementation detail. Updated comment. > > > + properties.setProperty("delete", Boolean.toString(true)); > > + } > > + > > + /** > > + * This locks the properties file so only one thing can access this > > entry at a time. > > + */ > > + protected void lock() { > > + CacheUtil.lockFile(properties); > > + } > > + > > + /** > > + * This unlocks the properties file. > > + */ > > + protected void unlock() { > > + CacheUtil.unlockFile(properties); > > + } > > + > > } > > diff -r 30276d468815 netx/net/sourceforge/jnlp/cache/CacheUtil.java > > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Fri Apr 01 > > 12:57:18 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 04 > > 12:13:32 2011 -0400 > > @@ -21,6 +21,8 @@ > > import java.io.*; > > import java.net.*; > > import java.nio.channels.FileChannel; > > +import java.nio.channels.FileLock; > > +import java.nio.channels.OverlappingFileLockException; > > import java.util.*; > > import java.security.*; > > import javax.jnlp.*; > > @@ -29,6 +31,7 @@ > > import net.sourceforge.jnlp.config.DeploymentConfiguration; > > import net.sourceforge.jnlp.runtime.*; > > import net.sourceforge.jnlp.util.FileUtils; > > +import net.sourceforge.jnlp.util.PropertiesFile; > > > > /** > > * Provides static methods to interact with the cache, download > > @@ -39,6 +42,15 @@ > > */ > > public class CacheUtil { > > > > + public static final String cacheDir = new > > File(JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)).getPath(); > > // Do this with file to standardize it. > > + public static final String recentlyUsed = cacheDir + > > File.separator + "RecentlyUsed"; > > + > > Please dont make variables that contain sensitive information (like > user's home dir) public. Made private. > > What happens if someone accidentally uses the CacheUtil class before > JNLPRuntime.initialize() is called? I think cacheDir will be null at > that point. yes it will be null, but I don't see why they should be using CacheUtil in the first place. > > I dont understand the comment... are you referring to canonicalizing > paths? getCanonicalPath() might be more appropriate. I was referring to have it give me a normalized path (such as removing redundant '/'). I am trying to refrain from calling getCanonicalPath(), getPath() should suffice. > > > + private static PropertiesFile cacheOrder = new PropertiesFile(new > > File(cacheDir + File.separator + "RecentlyUsed")); > > + private static HashMap propertiesLockPool = new > > HashMap(); > > + > > Perhaps these should be final? Added final identifier. > > > + private static FileLock fl = null; > > + private static int lockCount = 0; > > + > > /** > > * Compares a URL using string compare of its protocol, host, > > * port, path, query, and anchor. This method avoids the host > > @@ -138,8 +150,7 @@ > > return; > > } > > > > - File cacheDir = new File(JNLPRuntime.getConfiguration() > > - .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)); > > + File cacheDir = new File(CacheUtil.cacheDir); > > if (!(cacheDir.isDirectory())) { > > return; > > } > > @@ -284,18 +295,86 @@ > > if (!isCacheable(source, version)) > > throw new IllegalArgumentException(R("CNotCacheable", > > source)); > > > > - try { > > - String cacheDir = JNLPRuntime.getConfiguration() > > - .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR); > > - File localFile = urlToPath(source, cacheDir); > > - FileUtils.createParentDir(localFile); > > + File cacheFile = null; > > + File urlPath = urlToPath(source, ""); > > > > - return localFile; > > - } catch (Exception ex) { > > - if (JNLPRuntime.isDebug()) > > - ex.printStackTrace(); > > + lockRecentlyUsedFile(); > > + String folder = ""; > > + synchronized (cacheOrder) { // We can only look for one cache file > > at a time. Since if we open same applet twice same plugin that > > causes similar problems. > > Please try to keep lines under 80 chars, unless there is a good > reason. > > > + cacheOrder.load(); // Update hashtable. > > In complex code like this, please include comments that explain why > you > are doing things, not what you are doing. > > > + Set set = cacheOrder.keySet(); > > + if (set.size()> 0) { // There are items cached, we need to look > > through them. > > + String[] keys = set.toArray(new String[0]); > > + List listKeys = Arrays.asList(keys); > > + Collections.sort(listKeys); > > Can you please document the format of the RecentlyUsedFile? > > > > > - return null; > > + // We now want to start searching from the most recent to least > > recent. > > + for (int i = listKeys.size() - 1; i>= 0; i--) { > > + String str = cacheOrder.getProperty(listKeys.get(i)); > > + if (str != null) { > > + str = str.substring(cacheDir.length()); > > + int index = str.indexOf(File.separatorChar, 1); > > + folder = str.substring(1, index); > > + str = str.substring(index); > > + > > + if (str.equals(urlPath.getPath())) { // We found a match. Don't > > know if it is old though. > > + cacheFile = new File(cacheOrder.getProperty(listKeys.get(i))); > > + cacheOrder.remove(listKeys.get(i)); // We can remove this since we > > will add it back as updated. > > + break; // Stop searching since we got newest one already. > > + } > > + } > > + } > > + } > > + > > + if (cacheFile != null) { // We found a file above. > > + // We requested it recently so mark it as recent. > > + // We append folder to guarantee uniqueness. Since it might be too > > quick in calculations. > > + cacheOrder.put(Long.toString(System.currentTimeMillis()) + folder, > > cacheFile.getPath()); > > Hm... it's not obvious to me, but what ensures that the combination > "currentTimeMillis() + folder" is unique? Will this assumption hold > when > we have machines which are much faster? The folders are unique. Folders are created to house only one entry at a time. When creating the folders it blocks until a folder has been successfully added to the cacheOrder. Having just time alone is the issue with faster machines, but by appending a unique folder identifier to the end of current time, we get a new unique key and will preserve the ordering of access. > > > + cacheOrder.store(); > > + } else { // We did not find a copy of it. This will also add it to > > list. > > + cacheFile = makeNewCacheFile(source, version); > > + } > > + } > > Seems to me like this method is trying to do too much. Would it be > possible to move the policy (LRU) to somewhere else? I think it might > be > better if you have one class responsible for the actual policy. > Perhaps > another (class or method) for extracting and adding entires might make > this code a lot clearer to read. Hmm, I moved the check inside cacheOrder out to its own method, however didn't see a need to move the removing and adding entry to cacheOrder out. > > > + unlockRecentlyUsedFile(); > > + return cacheFile; > > + } > > + > > + /** > > + * This will create a new entry for the cache item. It is however > > + * not initialized but any future calls to getCacheFile with the > > + * source and version given to here, will cause it to return this > > item. > > + * @param source the source URL > > + * @param version the version id of the local file > > + * @return the file location in the cache. > > + */ > > + public static File makeNewCacheFile(URL source, Version version) { > > + synchronized (cacheOrder) { > > + lockRecentlyUsedFile(); > > + cacheOrder.load(); > > + > > + File cacheFile = null; > > + for (long i = 0; i< Long.MAX_VALUE; i++) { > > + String path = cacheDir + File.separator + i; > > + File cDir = new File(path); > > + if (!cDir.exists()) { > > What cleans up this directory? cleanCache() will remove the directory when it becomes old. > > > + // We can use this directory. > > + try { > > + cacheFile = urlToPath(source, path); > > + FileUtils.createParentDir(cacheFile); > > + File pf = new File(cacheFile.getPath() + ".info"); > > + FileUtils.createRestrictedFile(pf, true); // Create the info file > > for marking later. > > + cacheOrder.setProperty(Long.toString(System.currentTimeMillis()) + > > i, cacheFile.getPath()); > > + cacheOrder.store(); > > + } catch (IOException ioe) { > > + ioe.printStackTrace(); > > + } > > + > > + break; > > + } > > + } > > + > > + unlockRecentlyUsedFile(); > > + return cacheFile; > > } > > } > > > > @@ -436,4 +515,151 @@ > > } > > } > > > > + public static void cleanCache() { > > + if (okToClearCache()) { > > + long maxSize = -1; > > + try { > > + maxSize = > > Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); > > + maxSize = maxSize * 1024 * 1024; > > + } catch (NumberFormatException nfe) { > > + // This is fine, we will just default to infinite cache. > > + } > > + long totalSize = 0; > > + > > + // First we want to figure out which stuff we need to delete. > > + // There should not be any duplicate entries in cacheOrder, since > > we always clear old when setting new. > > + // Thus we don't need to search through that. > > + // We now go through all the entries and pick out the ones that > > aren't marked for delete starting from the back. > > + HashSet keep = new HashSet(); > > + cacheOrder.load(); > > + Set set = cacheOrder.keySet(); > > + String[] keys = set.toArray(new String[0]); > > + List listKeys = Arrays.asList(keys); > > + Collections.sort(listKeys); > > This code looks identical to the one above. I am qutie convinced this > should be abstracted away. Done. > > > + // We now want to start searching from the most recent to least > > recent. > > + for (int i = listKeys.size() - 1; i>= 0; i--) { > > + // Check if the item is contained in cacheOrder. > > + String str = cacheOrder.getProperty(listKeys.get(i)); > > + > > + if (str != null) { > > + File temp = new File(str); > > + PropertiesFile pf = new PropertiesFile(new File(str + ".info")); > > + boolean delete = Boolean.parseBoolean(pf.getProperty("delete")); > > + > > + // This will get me the root directory specific to this cache > > item. > > + String rStr = str.substring(cacheDir.length()); > > + rStr = cacheDir + rStr.substring(0, > > rStr.indexOf(File.separatorChar, 1)); > > + > > + if (temp.isFile()&& !delete&& (maxSize< -1 || totalSize + > > temp.length()< maxSize)&& > > !keep.contains(str.substring(rStr.length()))) { // File exist, might > > want to keep. > > Please split this across multiple lines. Perhaps even better, can you > write a method (with a more descriptive name) that evaulates this > conditional? This is related to enforcing cache limit, removed. > > > + totalSize += temp.length(); > > + // Since we are keeping it, we will delete any extra files > > extracted by JNLPClassLoader.activateJars(). > > + for (File f : temp.getParentFile().listFiles()) { > > + if (!f.getPath().equals(temp.getPath())&& > > !f.getPath().equals(pf.getStoreFile().getPath())) { > > + try { > > + FileUtils.recursiveDelete(f, f); > > + } catch (IOException e) { > > + e.printStackTrace(); > > + } > > + } > > + } > > + > > + keep.add(str.substring(rStr.length())); > > + keep.add(rStr); // We can just use the same map, since these two > > things are disjoint with each other. > > + } else { > > + temp = new File(rStr); > > + try { > > + FileUtils.recursiveDelete(temp, temp); > > + } catch (IOException e) { // It's ok if we can't delete the actual > > directory as long as files are deleted. It would just look messy. > > + e.printStackTrace(); > > + } > > + cacheOrder.remove(listKeys.get(i)); > > + } > > + } > > + } > > + cacheOrder.store(); > > + > > + // Not all items will exist in cacheOrder, thus we will need to > > remove them manually, but a majority of them should be removed by > > the above segment. > > + File temp = new File(cacheDir); > > + // Remove all folder not listed in keep. > > + for (File f : temp.listFiles()) { > > + String path = f.getPath(); > > + temp = new File(path); > > + if (temp.isDirectory()&& !keep.contains(temp.getPath())) { > > + try { > > + FileUtils.recursiveDelete(temp, temp); > > + } catch (IOException e) { > > + e.printStackTrace(); > > + } > > + } > > + } > > Can you elaborate a little more on this? What files are we deleting > here? Any files that are not tracked by the hashset keep, which tells us which file we are to not delete, since they are under the cache limit. Anything else not listed will be removed. This will also clean up the current cached items that exist before applying this patch. > > > + } > > + } > > + > > + /** > > + * Lock the property file and add it to our pool of locks. > > + * @param properties Property file to lock. > > + */ > > + public static void lockFile(PropertiesFile properties) { > > + File storeFile = properties.getStoreFile(); > > + try { > > + propertiesLockPool.put(storeFile.getPath(), > > FileUtils.getFileLock(storeFile.getPath(), false, true)); > > + } catch (OverlappingFileLockException e) { > > + } catch (FileNotFoundException e) { > > + e.printStackTrace(); > > + } > > + } > > + > > + /** > > + * Unlock the property file and remove it from our pool. > > + * Nothing happens if it wasn't locked. > > + * @param properties Property file to unlock. > > + */ > > + public static void unlockFile(PropertiesFile properties) { > > + File storeFile = properties.getStoreFile(); > > + FileLock fl = propertiesLockPool.get(storeFile.getPath()); > > + try { > > + if (fl == null) return; > > + fl.release(); > > + fl.channel().close(); > > + propertiesLockPool.remove(storeFile.getPath()); > > + } catch (IOException e) { > > + e.printStackTrace(); > > + } > > + } > > + > > + private static void lockRecentlyUsedFile() { > > + synchronized (recentlyUsed) { > > + try { > > + File f = new File(recentlyUsed); > > + if (!f.exists()) { > > + FileUtils.createParentDir(f); > > + FileUtils.createRestrictedFile(f, true); > > + } > > + fl = FileUtils.getFileLock(f.getPath(), false, true); > > + lockCount++; > > + } catch (OverlappingFileLockException e) { // if overlap we just > > increase the count. > > + lockCount++; > > + } catch (Exception e) { // We didn't get a lock.. > > + e.printStackTrace(); > > + } > > + } > > + } > > + > > + private static void unlockRecentlyUsedFile() { > > + synchronized (recentlyUsed) { > > + if (fl != null) { > > + lockCount--; > > + try { > > + if (lockCount == 0) { > > + fl.release(); > > + fl.channel().close(); > > + fl = null; > > + } > > + } catch (IOException e) { > > + e.printStackTrace(); > > + } > > + } > > + } > > + } > > + > > } > > diff -r 30276d468815 > > netx/net/sourceforge/jnlp/cache/ResourceTracker.java > > --- a/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Fri Apr > > 01 12:57:18 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Mon Apr > > 04 12:13:32 2011 -0400 > > @@ -630,6 +630,9 @@ > > private void downloadResource(Resource resource) { > > resource.fireDownloadEvent(); // fire DOWNLOADING > > > > + CacheEntry origEntry = new CacheEntry(resource.location, > > resource.downloadVersion); // This is where the jar file will be. > > + origEntry.lock(); > > + > > try { > > // create out second in case in does not exist > > URL realLocation = resource.getDownloadLocation(); > > @@ -666,58 +669,73 @@ > > } else if (gzip) { > > downloadLocation = new > > URL(downloadLocation.toString() + ".gz"); > > } > > + > > + CacheEntry finalEntry = new CacheEntry(downloadLocation, > > resource.downloadVersion); // This is where the jar/compressed file > > will be. > > + File downloadLocationFile = > > CacheUtil.getCacheFile(downloadLocation, resource.downloadVersion); > > > > - InputStream in = new BufferedInputStream(con.getInputStream()); > > - OutputStream out = CacheUtil.getOutputStream(downloadLocation, > > resource.downloadVersion); > > - byte buf[] = new byte[1024]; > > - int rlen; > > - > > - while (-1 != (rlen = in.read(buf))) { > > - resource.transferred += rlen; > > - out.write(buf, 0, rlen); > > - } > > - > > - in.close(); > > - out.close(); > > - > > - // explicitly close the URLConnection. > > - if (con instanceof HttpURLConnection) > > - ((HttpURLConnection) con).disconnect(); > > - > > - /* > > - * If the file was compressed, uncompress it. > > - */ > > - > > - if (packgz) { > > - GZIPInputStream gzInputStream = new GZIPInputStream(new > > FileInputStream( > > - CacheUtil.getCacheFile(downloadLocation, > > resource.downloadVersion))); > > - InputStream inputStream = new BufferedInputStream(gzInputStream); > > - > > - JarOutputStream outputStream = new JarOutputStream(new > > FileOutputStream( > > - CacheUtil.getCacheFile(resource.location, > > resource.downloadVersion))); > > - > > - Unpacker unpacker = Pack200.newUnpacker(); > > - unpacker.unpack(inputStream, outputStream); > > - > > - outputStream.close(); > > - inputStream.close(); > > - gzInputStream.close(); > > - } else if (gzip) { > > - GZIPInputStream gzInputStream = new GZIPInputStream(new > > FileInputStream(CacheUtil > > - .getCacheFile(downloadLocation, resource.downloadVersion))); > > - InputStream inputStream = new BufferedInputStream(gzInputStream); > > - > > - BufferedOutputStream outputStream = new BufferedOutputStream( > > - new FileOutputStream(CacheUtil.getCacheFile(resource.location, > > - resource.downloadVersion))); > > - > > - while (-1 != (rlen = inputStream.read(buf))) { > > - outputStream.write(buf, 0, rlen); > > + if (!downloadLocationFile.exists()) { > > How well does this interact with the download progress indicators? How > are they updated? This only puts the condition on the downloading, the status will change as if we did download the file. > > > + byte buf[] = new byte[1024]; > > + int rlen; > > + // Make sure we don't re-download the file. however it will wait > > as if it was downloading. > > + // (This is fine because file is not ready yet anyways) > > + InputStream in = new BufferedInputStream(con.getInputStream()); > > + OutputStream out = CacheUtil.getOutputStream(downloadLocation, > > resource.downloadVersion); > > + > > + while (-1 != (rlen = in.read(buf))) { > > + resource.transferred += rlen; > > + out.write(buf, 0, rlen); > > } > > - > > - outputStream.close(); > > - inputStream.close(); > > - gzInputStream.close(); > > + > > + in.close(); > > + out.close(); > > + > > + // explicitly close the URLConnection. > > + if (con instanceof HttpURLConnection) > > + ((HttpURLConnection) con).disconnect(); > > + > > + /* > > + * If the file was compressed, uncompress it. > > + */ > > + > > + if (packgz) { > > + GZIPInputStream gzInputStream = new GZIPInputStream(new > > FileInputStream( > > + CacheUtil.getCacheFile(downloadLocation, > > resource.downloadVersion))); > > + InputStream inputStream = new BufferedInputStream(gzInputStream); > > + origEntry.markForDelete(); > > + origEntry.store(); > > + finalEntry.markForDelete(); > > + finalEntry.store(); > > + > > + JarOutputStream outputStream = new JarOutputStream(new > > FileOutputStream( > > + CacheUtil.getCacheFile(resource.location, > > resource.downloadVersion))); > > + > > + Unpacker unpacker = Pack200.newUnpacker(); > > + unpacker.unpack(inputStream, outputStream); > > + > > + outputStream.close(); > > + inputStream.close(); > > + gzInputStream.close(); > > + } else if (gzip) { > > + GZIPInputStream gzInputStream = new GZIPInputStream(new > > FileInputStream(CacheUtil > > + .getCacheFile(downloadLocation, resource.downloadVersion))); > > + InputStream inputStream = new BufferedInputStream(gzInputStream); > > + origEntry.markForDelete(); > > + origEntry.store(); > > + finalEntry.markForDelete(); > > + finalEntry.store(); > > + > > + BufferedOutputStream outputStream = new BufferedOutputStream( > > + new FileOutputStream(CacheUtil.getCacheFile(resource.location, > > + resource.downloadVersion))); > > + > > + while (-1 != (rlen = inputStream.read(buf))) { > > + outputStream.write(buf, 0, rlen); > > + } > > + > > + outputStream.close(); > > + inputStream.close(); > > + gzInputStream.close(); > > + } > > } > > > > resource.changeStatus(DOWNLOADING, DOWNLOADED); > > @@ -734,6 +752,8 @@ > > lock.notifyAll(); // wake up wait's to check for > > completion > > } > > resource.fireDownloadEvent(); // fire ERROR > > + } finally { > > + origEntry.unlock(); > > } > > } > > > > @@ -744,6 +764,9 @@ > > private void initializeResource(Resource resource) { > > resource.fireDownloadEvent(); // fire CONNECTING > > > > + CacheEntry entry = new CacheEntry(resource.location, > > resource.requestVersion); > > + entry.lock(); > > + > > try { > > File localFile = > > CacheUtil.getCacheFile(resource.location, > > resource.downloadVersion); > > > > @@ -755,6 +778,17 @@ > > > > int size = connection.getContentLength(); > > boolean current = > > CacheUtil.isCurrent(resource.location, > > resource.requestVersion, connection)&& > > resource.getUpdatePolicy() != UpdatePolicy.FORCE; > > + if (!current) { > > + if (entry.isCached()) { > > + entry.markForDelete(); > > + entry.store(); > > + localFile = CacheUtil.makeNewCacheFile(resource.location, > > resource.downloadVersion); > > + CacheEntry newEntry = new CacheEntry(resource.location, > > resource.requestVersion); > > + newEntry.lock(); > > + entry.unlock(); > > + entry = newEntry; > > + } > > + } > > > > synchronized (resource) { > > resource.localFile = localFile; > > @@ -768,7 +802,6 @@ > > } > > > > // update cache entry > > - CacheEntry entry = new CacheEntry(resource.location, > > resource.requestVersion); > > if (!current) > > entry.initialize(connection); > > > > @@ -792,6 +825,8 @@ > > lock.notifyAll(); // wake up wait's to check for > > completion > > } > > resource.fireDownloadEvent(); // fire ERROR > > + } finally { > > + entry.unlock(); > > } > > } > > > > diff -r 30276d468815 > > netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java > > --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Fri Apr > > 01 12:57:18 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Mon Apr > > 04 12:13:32 2011 -0400 > > @@ -166,11 +166,11 @@ > > // initialize extensions > > initializeExtensions(); > > > > + initializeResources(); > > + > > // initialize permissions > > initializePermissions(); > > > > - initializeResources(); > > - > > setSecurity(); > > > > installShutdownHooks(); > > diff -r 30276d468815 > > netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java > > --- a/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Fri Apr 01 > > 12:57:18 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java Mon Apr 04 > > 12:13:32 2011 -0400 > > @@ -701,6 +701,7 @@ > > Runtime.getRuntime().addShutdownHook(new Thread() { > > public void run() { > > markNetxStopped(); > > + CacheUtil.cleanCache(); > > } > > }); > > } > > diff -r 30276d468815 netx/net/sourceforge/jnlp/util/FileUtils.java > > --- a/netx/net/sourceforge/jnlp/util/FileUtils.java Fri Apr 01 > > 12:57:18 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/util/FileUtils.java Mon Apr 04 > > 12:13:32 2011 -0400 > > @@ -19,7 +19,11 @@ > > import static net.sourceforge.jnlp.runtime.Translator.R; > > > > import java.io.File; > > +import java.io.FileNotFoundException; > > import java.io.IOException; > > +import java.io.RandomAccessFile; > > +import java.nio.channels.FileChannel; > > +import java.nio.channels.FileLock; > > > > import net.sourceforge.jnlp.runtime.JNLPRuntime; > > > > @@ -292,4 +296,42 @@ > > > > } > > > > + /** > > + * This will return a lock to the file specified. > > + * > > + * @param name Name of the file to get lock from. > > Is this the file name or the file path? File path, but file name works too if you know you're in the right directory. :) > > > + * @param shared Specify if the lock will be a shared lock. > > + * @param allowBlock Specify if we should block when we can not get > > the > > + * lock. No effect when trying to get shared lock. > > What does no effect mean? Will it always block? Yes regardless of their choice of true or false, it will always block. Reworded it to make more sense. > > > + * @return FileLock if we were successful in getting a lock, > > otherwise null. > > + * @throws FileNotFoundException If the file does not exist. > > + */ > > + public static FileLock getFileLock(String name, boolean shared, > > boolean allowBlock) throws FileNotFoundException { > > + RandomAccessFile rafFile = new RandomAccessFile(name, "rw"); > > + FileChannel fc = rafFile.getChannel(); > > + FileLock lock = null; > > + try { > > + if (!shared) { > > + if (allowBlock) { > > + lock = fc.lock(0, Long.MAX_VALUE, false); > > + } else { > > + lock = fc.tryLock(0, Long.MAX_VALUE, false); > > + } > > + } else { // We want shared lock. This will block regardless if > > allowBlock is true or not. > > + // Test to see if we can get a shared lock. > > + lock = fc.lock(0, 1, true); // Block if a non exclusive lock is > > being held. > > + if (!lock.isShared()) { // This lock is an exclusive lock. Use > > alternate solution. > > + FileLock tempLock = null; > > + for (long pos = 1; tempLock == null&& pos< Long.MAX_VALUE - 1; > > pos++) { > > + tempLock = fc.tryLock(pos, 1, false); > > + } > > + lock.release(); > > + lock = tempLock; // Get the unique exclusive lock. > > + } > > Since we are emulating a shared lock using exclusive locks in a number > of places (I recall seeing another patch before that was doing this), > can we plese implement this in a separate class and reuse that rather > than implementing this in a buch of places? I think putting this in FileUtils is a suitable place. Especially since the file locks are associated with files. (I wanted to do that as a different changeset) Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110404_cache_v10.patch Type: text/x-patch Size: 25945 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110404/d66824c6/20110404_cache_v10.patch From omajid at redhat.com Mon Apr 4 15:50:15 2011 From: omajid at redhat.com (Omair Majid) Date: Mon, 04 Apr 2011 18:50:15 -0400 Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <415999679.375498.1301953547448.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <415999679.375498.1301953547448.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4D9A4B27.5040705@redhat.com> On 04/04/2011 05:45 PM, Andrew Su wrote: >>> I think this patch would be easier to review if you split it into >>> two patches - one to fix problems with files being overwritten, >>> and another to enforce cache sizes. > I've removed the section which will ensure the cache limit. Will post > that later. > Thanks! > + /** > + * This will return a File pointing to the location of cache item. > + * @param urlPath Path of cache item within cache directory. > + * @return File if we have searched before, null otherwise. > + */ > + private static File getCacheFileIfExist(File urlPath){ Instead of nitpicking, I am going to ask you to post some information about the files added/modified. I missed this during the original review (I suppose that might be a code smell and we need to do some refactoring), but now I see that this patch introduces and/or modifies a number of files: RecentlyUsed, per cache-entry directory, and possibly more metadata. Could you please describe what the overall design of this cache is? What data each file contains? And in what format? I would love it if the response consists of patch with a new class per file/directory introduced/modified/repurposed and each class contains (as comments) the purpose and format :D Cheers, Omair From jvanek at redhat.com Mon Apr 4 23:47:06 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 05 Apr 2011 08:47:06 +0200 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser In-Reply-To: <4D99C03F.9040303@redhat.com> References: <4D99C03F.9040303@redhat.com> Message-ID: <4D9ABAEA.4050203@redhat.com> On 04/04/2011 02:57 PM, Jiri Vanek wrote: If somebody have recieved this twice, then sorry - I have suspicion that my email client is broken:-/ The emails from me to me are not delivered:-/ > > > -------- Original Message -------- > Subject: Re: [icedtea-web] RFC: add unit tests for the jnlp parser > Date: Mon, 04 Apr 2011 13:45:15 +0200 > From: Jiri Vanek > To: distro-pkg-dev at openjdk.java.net > > On 04/01/2011 11:54 PM, Omair Majid wrote: >> On 03/31/2011 04:56 PM, Dr Andrew John Hughes wrote: >>> On 15:30 Thu 31 Mar , Omair Majid wrote: >>>> On 03/31/2011 02:26 PM, Dr Andrew John Hughes wrote: >>>>> On 13:40 Thu 31 Mar , Omair Majid wrote: >>>>>> On 03/30/2011 08:21 PM, Dr Andrew John Hughes wrote: >>>>>>> >>>>>>> It does need documenting in README, but I'm happy for that to be a >>>>>>> separate patch. >>>>>> >>>>>> Patch attached. Does that look okay? >>>>>> >>>>> >>>>> It's a bit brief. >>>>> >>>>> * What about documenting the --with-rhino/junit options? >>>>> * What about something specific about the JUnit tests? >>>> >>>> Okay, how about the new patch? >>>> >>> Still nothing on the JUnit stuff, which was the main reason I thought >>> we were >>> patching the docs. The custom output and the reasoning for it should >>> be noted >>> IMHO. >>> >> >> Ah, _now_ I get it. I thought by JUnit, you were referring to JUnit >> itself, not our frontend/formatter for it. >> >> I thought my documentation of that in tests/junit-runner/README was >> sufficient. Anyway, I have updated the README for that too. Any other >> suggestions? >> >> Cheers, >> Omair Today I have tested and walked through junit test for netx. Compraed to TestNg I consider it as big step back. I still do not see, why 3jars of easily downloadable dependences (can be handled as drops), one nicely-readable xml and annotations configuration and few lines of make.am/configure and extremely good looking and informing output and clear license was abandoned for one jar of dependence, mess makefile, nearly no configuration posibility, and custom java-class luncher (extending such a complex thing can always bring troubles and much confusion inside), maybe confusing license and its quite strange application (I'm not deep enough in it). TestNG - advantages - output, configuration(this is huge problem in JUnit), small makefile integration, license, documentation disadvantages - 2 more jars as dependencies JUnit - advantages - no dependences disadvantages - output, custom java-class luncher, no configuration, license, to much of makefile in (find *class... :-/// ) Google can be my witness;) http://www.google.com/search?q=junit+testng+comparison Basicly I do not agree with Andrews arguments against TestNG. Eg. Deepak agreed with them. Omair found them sufficient, And I'm finding them much better. Sorry for post-commit reaction but I have overlooked swap testng->junit in distro emails. Regards J. From ahughes at redhat.com Tue Apr 5 05:12:41 2011 From: ahughes at redhat.com (Andrew John Hughes) Date: Tue, 5 Apr 2011 13:12:41 +0100 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser In-Reply-To: <4D964998.5010807@redhat.com> References: <20110330162147.GK6143@rivendell.middle-earth.co.uk> <4D93745B.9050006@redhat.com> <20110330220857.GH6143@rivendell.middle-earth.co.uk> <4D93C5ED.5000501@redhat.com> <20110331002116.GO6143@rivendell.middle-earth.co.uk> <4D94BC8E.5020301@redhat.com> <20110331182651.GE6143@rivendell.middle-earth.co.uk> <4D94D654.3020306@redhat.com> <20110331205614.GI6143@rivendell.middle-earth.co.uk> <4D964998.5010807@redhat.com> Message-ID: <20110405121241.GA2799@shelob.middle-earth.co.uk> On Fri, Apr 01, 2011 at 05:54:32PM -0400, Omair Majid wrote: > On 03/31/2011 04:56 PM, Dr Andrew John Hughes wrote: > >On 15:30 Thu 31 Mar , Omair Majid wrote: > >>On 03/31/2011 02:26 PM, Dr Andrew John Hughes wrote: > >>>On 13:40 Thu 31 Mar , Omair Majid wrote: > >>>>On 03/30/2011 08:21 PM, Dr Andrew John Hughes wrote: > >>>>> > >>>>>It does need documenting in README, but I'm happy for that to be a separate patch. > >>>> > >>>>Patch attached. Does that look okay? > >>>> > >>> > >>>It's a bit brief. > >>> > >>>* What about documenting the --with-rhino/junit options? > >>>* What about something specific about the JUnit tests? > >> > >>Okay, how about the new patch? > >> > >Still nothing on the JUnit stuff, which was the main reason I thought we were > >patching the docs. The custom output and the reasoning for it should be noted > >IMHO. > > > > Ah, _now_ I get it. I thought by JUnit, you were referring to JUnit > itself, not our frontend/formatter for it. > Sorry, should have been clearer. > I thought my documentation of that in tests/junit-runner/README was > sufficient. Anyway, I have updated the README for that too. Any > other suggestions? Ok, I'd forgotten about that file. The changes aren't in the patch below, though... > > Cheers, > Omair > diff -r 1d604ccd9b6b README > --- a/README Thu Mar 31 18:19:31 2011 -0400 > +++ b/README Fri Apr 01 12:43:20 2011 -0400 > @@ -66,6 +66,11 @@ > > The plugin can be disabled by passing --disable-plugin. > > +The following optional dependencies enable additional features > + > +* rhino (enables support for using proxy auto config files) > +* junit4 (enables unit tests) > + > See ./configure --help if you need to override the defaults. > > The following locations are checked for a JDK: > @@ -113,10 +118,50 @@ > These are documented fully in the relevant section below. > > * --disable-plugin: Don't build the browser plugin. > +* --with-rhino: Specify the location of rhino jar > +* --with-junit: Specify the location of the junit 4 jar > + > +Rhino Support > +============= > + > +IcedTea-Web needs rhino for using Proxy Auto Config (PAC) files. If rhino is > +not found, or explicitly disabled, then support for PAC files will be disabled. > + > +By default, the following paths are checked for rhino: > + - /usr/share/java/js.jar > + - /usr/share/rhino-1.6/lib/js.jar > + - /usr/share/java/rhino.jar > + > +If a rhino jar is not found, rhino support is disabled. The --with-rhino build > +option can be used to specify the location of the jar file. To explicitly > +disable rhino use --with-rhino=no. > + > +JUnit Support > +============= > + > +JUnit is needed for running some tests. It has no run-time impact. > + > +By default, the following paths are checked: > + - /usr/share/java/junit4.jar > + > +If JUnit is not found, JUnit support is disabled. The --with-junit option can > +be used to specify the location of the JUnit 4 jar. To disable JUnit support > +explicitly, use --with-junit=no. > + > +A custom JUnit ouput formatter is supplied. This makes the output of JUnit > +tests match the output of other tests. A simple 'Passed:' or 'FAILED:' is > +printed out, followed by .. This is also the format used > +by JTreg. > > Testing > ======= > > +A set of automated tests is supplied for IcedTea-Web. They can be run by using > +'make check'. Currently, this only tests a few parts of IcedTea-Web. > + > +The number and type of tests run by 'make check' may be affected by the build > +options, including JUnit support and rhino support. > + > A test suite is supplied for the browser plugin. It can be built > using 'make plugin-tests' and run by loading the HTML page specified > into a browser with the plugin installed. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Tue Apr 5 07:27:43 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 5 Apr 2011 10:27:43 -0400 Subject: [RFC][plugin]: class in CWD can block applet from loading. In-Reply-To: <821548235.1571593.1301423856656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1050106310.1571312.1301423314107.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <821548235.1571593.1301423856656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110405142743.GB14541@redhat.com> * Denis Lila [2011-03-29 14:38]: > Hi. > After a fair bit of investigation on other possible solutions by Denis, this seems to be the best way. > + { > + command_line = (gchar**) malloc(sizeof(gchar*)*8); > + command_line[cmd_num++] = g_strdup(appletviewer_executable); > + command_line[cmd_num++] = g_strdup(PLUGIN_BOOTCLASSPATH); > + command_line[cmd_num++] = g_strdup("-classpath"); > + command_line[cmd_num++] = g_strdup("~/.icedtea"); The patch is mostly fine, but the -classpath should not be set to .icedtea. We store a lot of things in .icedtea. It is technically possible for a malicious applet to access items in .icedtea, which include not just cache, but things like trusted certificate list. Furthermore, ~/.icedtea exposes user.home I would set it to ICEDTEA_WEB_JRE/lib/rt.jar Cheers, Deepak > + command_line[cmd_num++] = g_strdup("sun.applet.PluginMain"); > + command_line[cmd_num++] = g_strdup(out_pipe_name); > + command_line[cmd_num++] = g_strdup(in_pipe_name); > + command_line[cmd_num] = NULL; > + } > > environment = plugin_filter_environment(); > > @@ -1590,25 +1595,9 @@ > > g_strfreev (environment); > > - g_free (command_line[0]); > - command_line[0] = NULL; > - g_free (command_line[1]); > - command_line[1] = NULL; > - g_free (command_line[2]); > - command_line[2] = NULL; > - g_free (command_line[3]); > - command_line[3] = NULL; > - g_free (command_line[4]); > - command_line[4] = NULL; > - > - if (plugin_debug) > - { > - g_free (command_line[5]); > - command_line[5] = NULL; > - g_free (command_line[6]); > - command_line[6] = NULL; > - g_free (command_line[7]); > - command_line[7] = NULL; > + for (int i = 0; i < cmd_num; i++) { > + g_free (command_line[i]); > + command_line[i] = NULL; > } > > g_free(command_line); From omajid at redhat.com Tue Apr 5 07:36:19 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 05 Apr 2011 10:36:19 -0400 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser In-Reply-To: <20110405121241.GA2799@shelob.middle-earth.co.uk> References: <20110330162147.GK6143@rivendell.middle-earth.co.uk> <4D93745B.9050006@redhat.com> <20110330220857.GH6143@rivendell.middle-earth.co.uk> <4D93C5ED.5000501@redhat.com> <20110331002116.GO6143@rivendell.middle-earth.co.uk> <4D94BC8E.5020301@redhat.com> <20110331182651.GE6143@rivendell.middle-earth.co.uk> <4D94D654.3020306@redhat.com> <20110331205614.GI6143@rivendell.middle-earth.co.uk> <4D964998.5010807@redhat.com> <20110405121241.GA2799@shelob.middle-earth.co.uk> Message-ID: <4D9B28E3.4020600@redhat.com> On 04/05/2011 08:12 AM, Andrew John Hughes wrote: > On Fri, Apr 01, 2011 at 05:54:32PM -0400, Omair Majid wrote: >> On 03/31/2011 04:56 PM, Dr Andrew John Hughes wrote: >>> On 15:30 Thu 31 Mar , Omair Majid wrote: >>>> On 03/31/2011 02:26 PM, Dr Andrew John Hughes wrote: >>>>> On 13:40 Thu 31 Mar , Omair Majid wrote: >>>>>> On 03/30/2011 08:21 PM, Dr Andrew John Hughes wrote: >>>>>>> >>>>>>> It does need documenting in README, but I'm happy for that to be a separate patch. >>>>>> >>>>>> Patch attached. Does that look okay? >>>>>> >>>>> >>>>> It's a bit brief. >>>>> >>>>> * What about documenting the --with-rhino/junit options? >>>>> * What about something specific about the JUnit tests? >>>> >>>> Okay, how about the new patch? >>>> >>> Still nothing on the JUnit stuff, which was the main reason I thought we were >>> patching the docs. The custom output and the reasoning for it should be noted >>> IMHO. >>> >> >> Ah, _now_ I get it. I thought by JUnit, you were referring to JUnit >> itself, not our frontend/formatter for it. >> > > Sorry, should have been clearer. > No worries. >> I thought my documentation of that in tests/junit-runner/README was >> sufficient. Anyway, I have updated the README for that too. Any >> other suggestions? > > Ok, I'd forgotten about that file. The changes aren't in the patch below, though... > This bit below is what I was referring to: >> +A custom JUnit ouput formatter is supplied. This makes the output of JUnit >> +tests match the output of other tests. A simple 'Passed:' or 'FAILED:' is >> +printed out, followed by.. This is also the format used >> +by JTreg. Cheers, Omair From dlila at redhat.com Tue Apr 5 09:01:49 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 5 Apr 2011 12:01:49 -0400 (EDT) Subject: [RFC][plugin]: class in CWD can block applet from loading. In-Reply-To: <20110405142743.GB14541@redhat.com> Message-ID: <1930808588.1960050.1302019309350.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > We store a lot of things in .icedtea. It is technically possible for > a malicious applet to access items in .icedtea, which include not just > cache, but things like trusted certificate list. > > Furthermore, ~/.icedtea exposes user.home I see. > I would set it to ICEDTEA_WEB_JRE/lib/rt.jar The attached patch does that. It also includes the fix for javaws. Is it ok? ChangeLog: +2011-04-05 Denis Lila + + * plugin/icedteanp/IcedTeaNPPlugin.cc + (plugin_start_appletviewer): Replace hardcoded indices + with a variable; roll up free calls in a loop; fix whitespace; + set classpath to ICEDTEA_WEB_JRE/lib/rt.jar. + * launcher/javaws.in: + Set class path to JRE/lib/rt.jar. + * Makefile.am: + Replace @JRE@ with $(JRE) in edit_launcher_script. + Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-03-29 14:38]: > > Hi. > > > > After a fair bit of investigation on other possible solutions by > Denis, > this seems to be the best way. > > > + { > > + command_line = (gchar**) malloc(sizeof(gchar*)*8); > > + command_line[cmd_num++] = g_strdup(appletviewer_executable); > > + command_line[cmd_num++] = g_strdup(PLUGIN_BOOTCLASSPATH); > > + command_line[cmd_num++] = g_strdup("-classpath"); > > + command_line[cmd_num++] = g_strdup("~/.icedtea"); > > > The patch is mostly fine, but the -classpath should not be set to > .icedtea. > > > Cheers, > Deepak > > > + command_line[cmd_num++] = g_strdup("sun.applet.PluginMain"); > > + command_line[cmd_num++] = g_strdup(out_pipe_name); > > + command_line[cmd_num++] = g_strdup(in_pipe_name); > > + command_line[cmd_num] = NULL; > > + } > > > > environment = plugin_filter_environment(); > > > > @@ -1590,25 +1595,9 @@ > > > > g_strfreev (environment); > > > > - g_free (command_line[0]); > > - command_line[0] = NULL; > > - g_free (command_line[1]); > > - command_line[1] = NULL; > > - g_free (command_line[2]); > > - command_line[2] = NULL; > > - g_free (command_line[3]); > > - command_line[3] = NULL; > > - g_free (command_line[4]); > > - command_line[4] = NULL; > > - > > - if (plugin_debug) > > - { > > - g_free (command_line[5]); > > - command_line[5] = NULL; > > - g_free (command_line[6]); > > - command_line[6] = NULL; > > - g_free (command_line[7]); > > - command_line[7] = NULL; > > + for (int i = 0; i < cmd_num; i++) { > > + g_free (command_line[i]); > > + command_line[i] = NULL; > > } > > > > g_free(command_line); -------------- next part -------------- A non-text attachment was scrubbed... Name: hg.diff Type: text/x-patch Size: 5378 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110405/1817b72d/hg.diff From dlila at redhat.com Tue Apr 5 09:13:20 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 5 Apr 2011 12:13:20 -0400 (EDT) Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <1220523441.1960231.1302019863798.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1086482658.1960260.1302020000656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. I think I found a concurrency problem in ResourceTracker.addResource. This method is not static. It is called from different threads, and it writes to downloadOptions which is a static HashMap. This is not safe. The patch uses a ConcurrentHashMap. That should be enough to fix it. Ok to push? Regards, Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: downloadOptionsConcurrent.patch Type: text/x-patch Size: 1447 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110405/da3fbc85/downloadOptionsConcurrent.patch From aph at redhat.com Tue Apr 5 09:18:54 2011 From: aph at redhat.com (Andrew Haley) Date: Tue, 05 Apr 2011 17:18:54 +0100 Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <1086482658.1960260.1302020000656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1086482658.1960260.1302020000656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4D9B40EE.9050105@redhat.com> On 04/05/2011 05:13 PM, Denis Lila wrote: > I think I found a concurrency problem in > ResourceTracker.addResource. This method is not static. > It is called from different threads, and it writes to > downloadOptions which is a static HashMap. This is not > safe. The patch uses a ConcurrentHashMap. That should > be enough to fix it. If you need the Map to be safe for concurrent access, then you should say so in its type, no? Andrew. From dbhole at redhat.com Tue Apr 5 09:20:06 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 5 Apr 2011 12:20:06 -0400 Subject: [RFC][plugin]: class in CWD can block applet from loading. In-Reply-To: <1930808588.1960050.1302019309350.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110405142743.GB14541@redhat.com> <1930808588.1960050.1302019309350.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110405162005.GA16524@redhat.com> * Denis Lila [2011-04-05 12:01]: > > We store a lot of things in .icedtea. It is technically possible for > > a malicious applet to access items in .icedtea, which include not just > > cache, but things like trusted certificate list. > > > > Furthermore, ~/.icedtea exposes user.home > > I see. > > > I would set it to ICEDTEA_WEB_JRE/lib/rt.jar > > The attached patch does that. It also includes the fix for javaws. > Is it ok? > Yep, looks fine now. Okay for HEAD. Deepak From dlila at redhat.com Tue Apr 5 09:21:48 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 5 Apr 2011 12:21:48 -0400 (EDT) Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <4D9B40EE.9050105@redhat.com> Message-ID: <1348540489.1960397.1302020508421.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > If you need the Map to be safe for concurrent access, then you should > say so in its type, no? That's a good point. Is it ok to push after I change "Map" to "ConcurrentHashMap"? (I would like to avoid another patch for such a small change) Thank you, Denis. ----- Original Message ----- > On 04/05/2011 05:13 PM, Denis Lila wrote: > > > I think I found a concurrency problem in > > ResourceTracker.addResource. This method is not static. > > It is called from different threads, and it writes to > > downloadOptions which is a static HashMap. This is not > > safe. The patch uses a ConcurrentHashMap. That should > > be enough to fix it. > > > Andrew. From dlila at icedtea.classpath.org Tue Apr 5 09:23:39 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Tue, 05 Apr 2011 16:23:39 +0000 Subject: /hg/icedtea-web: Set class path to JRE/lib/rt.jar for both plugi... Message-ID: changeset 62011060e7ea in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=62011060e7ea author: Denis Lila date: Tue Apr 05 12:07:10 2011 -0400 Set class path to JRE/lib/rt.jar for both plugin and javaws. diffstat: ChangeLog | 11 +++++ Makefile.am | 3 +- launcher/javaws.in | 2 + plugin/icedteanp/IcedTeaNPPlugin.cc | 70 +++++++++++++++--------------------- 4 files changed, 45 insertions(+), 41 deletions(-) diffs (144 lines): diff -r 30276d468815 -r 62011060e7ea ChangeLog --- a/ChangeLog Fri Apr 01 12:57:18 2011 -0400 +++ b/ChangeLog Tue Apr 05 12:07:10 2011 -0400 @@ -1,3 +1,14 @@ +2011-04-05 Denis Lila + + * plugin/icedteanp/IcedTeaNPPlugin.cc + (plugin_start_appletviewer): Replace hardcoded indices + with a variable; roll up free calls in a loop; fix whitespace; + set classpath to ICEDTEA_WEB_JRE/lib/rt.jar. + * launcher/javaws.in: + Set class path to JRE/lib/rt.jar. + * Makefile.am: + Replace @JRE@ with $(JRE) in edit_launcher_script. + 2011-04-01 Denis Lila * plugin/icedteanp/java/sun/applet/PluginDebug.java: diff -r 30276d468815 -r 62011060e7ea Makefile.am --- a/Makefile.am Fri Apr 01 12:57:18 2011 -0400 +++ b/Makefile.am Tue Apr 05 12:07:10 2011 -0400 @@ -115,7 +115,8 @@ -e 's|[@]LAUNCHER_BOOTCLASSPATH[@]|$(LAUNCHER_BOOTCLASSPATH)|g' \ -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/javaws|g' \ -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/itweb-settings|g' \ - -e 's|[@]JAVA[@]|$(JAVA)|g' + -e 's|[@]JAVA[@]|$(JAVA)|g' \ + -e 's|[@]JRE[@]|$(JRE)|g' # Top-Level Targets # ================= diff -r 30276d468815 -r 62011060e7ea launcher/javaws.in --- a/launcher/javaws.in Fri Apr 01 12:57:18 2011 -0400 +++ b/launcher/javaws.in Tue Apr 05 12:07:10 2011 -0400 @@ -6,6 +6,7 @@ CLASSNAME=net.sourceforge.jnlp.runtime.Boot BINARY_LOCATION=@JAVAWS_BIN_LOCATION@ PROGRAM_NAME=javaws +CP=@JRE@/lib/rt.jar JAVA_ARGS= ARGS= @@ -24,6 +25,7 @@ ${JAVA} ${LAUNCHER_BOOTCLASSPATH} ${LAUNCHER_FLAGS} \ ${JAVA_ARGS} \ + -classpath ${CP} \ -Dicedtea-web.bin.name=${PROGRAM_NAME} \ -Dicedtea-web.bin.location=${BINARY_LOCATION} \ ${CLASSNAME} \ diff -r 30276d468815 -r 62011060e7ea plugin/icedteanp/IcedTeaNPPlugin.cc --- a/plugin/icedteanp/IcedTeaNPPlugin.cc Fri Apr 01 12:57:18 2011 -0400 +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc Tue Apr 05 12:07:10 2011 -0400 @@ -1541,34 +1541,40 @@ gchar** command_line; gchar** environment; + int cmd_num = 0; if (plugin_debug) { - command_line = (gchar**) malloc(sizeof(gchar*)*9); - command_line[0] = g_strdup(appletviewer_executable); - command_line[1] = g_strdup(PLUGIN_BOOTCLASSPATH); - command_line[2] = g_strdup("-Xdebug"); - command_line[3] = g_strdup("-Xnoagent"); + command_line = (gchar**) malloc(sizeof(gchar*)*11); + command_line[cmd_num++] = g_strdup(appletviewer_executable); + command_line[cmd_num++] = g_strdup(PLUGIN_BOOTCLASSPATH); + // set the classpath to avoid using the default (cwd). + command_line[cmd_num++] = g_strdup("-classpath"); + command_line[cmd_num++] = g_strdup_printf("%s/lib/rt.jar", ICEDTEA_WEB_JRE); + command_line[cmd_num++] = g_strdup("-Xdebug"); + command_line[cmd_num++] = g_strdup("-Xnoagent"); if (plugin_debug_suspend) { - command_line[4] = g_strdup("-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y"); + command_line[cmd_num++] = g_strdup("-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=y"); } else { - command_line[4] = g_strdup("-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"); + command_line[cmd_num++] = g_strdup("-Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n"); } - command_line[5] = g_strdup("sun.applet.PluginMain"); - command_line[6] = g_strdup(out_pipe_name); - command_line[7] = g_strdup(in_pipe_name); - command_line[8] = NULL; - } else - { - command_line = (gchar**) malloc(sizeof(gchar*)*6); - command_line[0] = g_strdup(appletviewer_executable); - command_line[1] = g_strdup(PLUGIN_BOOTCLASSPATH); - command_line[2] = g_strdup("sun.applet.PluginMain"); - command_line[3] = g_strdup(out_pipe_name); - command_line[4] = g_strdup(in_pipe_name); - command_line[5] = NULL; - } + command_line[cmd_num++] = g_strdup("sun.applet.PluginMain"); + command_line[cmd_num++] = g_strdup(out_pipe_name); + command_line[cmd_num++] = g_strdup(in_pipe_name); + command_line[cmd_num] = NULL; + } else + { + command_line = (gchar**) malloc(sizeof(gchar*)*8); + command_line[cmd_num++] = g_strdup(appletviewer_executable); + command_line[cmd_num++] = g_strdup(PLUGIN_BOOTCLASSPATH); + command_line[cmd_num++] = g_strdup("-classpath"); + command_line[cmd_num++] = g_strdup_printf("%s/lib/rt.jar", ICEDTEA_WEB_JRE); + command_line[cmd_num++] = g_strdup("sun.applet.PluginMain"); + command_line[cmd_num++] = g_strdup(out_pipe_name); + command_line[cmd_num++] = g_strdup(in_pipe_name); + command_line[cmd_num] = NULL; + } environment = plugin_filter_environment(); @@ -1590,25 +1596,9 @@ g_strfreev (environment); - g_free (command_line[0]); - command_line[0] = NULL; - g_free (command_line[1]); - command_line[1] = NULL; - g_free (command_line[2]); - command_line[2] = NULL; - g_free (command_line[3]); - command_line[3] = NULL; - g_free (command_line[4]); - command_line[4] = NULL; - - if (plugin_debug) - { - g_free (command_line[5]); - command_line[5] = NULL; - g_free (command_line[6]); - command_line[6] = NULL; - g_free (command_line[7]); - command_line[7] = NULL; + for (int i = 0; i < cmd_num; i++) { + g_free (command_line[i]); + command_line[i] = NULL; } g_free(command_line); From dlila at redhat.com Tue Apr 5 09:24:10 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 5 Apr 2011 12:24:10 -0400 (EDT) Subject: [RFC][plugin]: class in CWD can block applet from loading. In-Reply-To: <20110405162005.GA16524@redhat.com> Message-ID: <1239444074.1960476.1302020650179.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Yep, looks fine now. Okay for HEAD. Thanks for the review. I pushed it. Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-05 12:01]: > > > We store a lot of things in .icedtea. It is technically possible > > > for > > > a malicious applet to access items in .icedtea, which include not > > > just > > > cache, but things like trusted certificate list. > > > > > > Furthermore, ~/.icedtea exposes user.home > > > > I see. > > > > > I would set it to ICEDTEA_WEB_JRE/lib/rt.jar > > > > The attached patch does that. It also includes the fix for javaws. > > Is it ok? > > > > > Deepak From aph at redhat.com Tue Apr 5 09:28:29 2011 From: aph at redhat.com (Andrew Haley) Date: Tue, 05 Apr 2011 17:28:29 +0100 Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <1348540489.1960397.1302020508421.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1348540489.1960397.1302020508421.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4D9B432D.2050202@redhat.com> On 04/05/2011 05:21 PM, Denis Lila wrote: >> If you need the Map to be safe for concurrent access, then you should >> say so in its type, no? > > That's a good point. Is it ok to push after I > change "Map" to "ConcurrentHashMap"? (I would like to avoid > another patch for such a small change) Yes. Andrew. From dlila at icedtea.classpath.org Tue Apr 5 09:35:27 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Tue, 05 Apr 2011 16:35:27 +0000 Subject: /hg/icedtea-web: Fix concurrent access problem to downloadOptions. Message-ID: changeset 9c89214b7ef6 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=9c89214b7ef6 author: Denis Lila date: Tue Apr 05 12:39:14 2011 -0400 Fix concurrent access problem to downloadOptions. diffstat: ChangeLog | 6 ++++++ netx/net/sourceforge/jnlp/cache/ResourceTracker.java | 7 +++---- 2 files changed, 9 insertions(+), 4 deletions(-) diffs (38 lines): diff -r 62011060e7ea -r 9c89214b7ef6 ChangeLog --- a/ChangeLog Tue Apr 05 12:07:10 2011 -0400 +++ b/ChangeLog Tue Apr 05 12:39:14 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-05 Denis Lila + + * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: + Remove unused imports, add import. + (downloadOptions): Make ConcurrentHashMap. + 2011-04-05 Denis Lila * plugin/icedteanp/IcedTeaNPPlugin.cc diff -r 62011060e7ea -r 9c89214b7ef6 netx/net/sourceforge/jnlp/cache/ResourceTracker.java --- a/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Tue Apr 05 12:07:10 2011 -0400 +++ b/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Tue Apr 05 12:39:14 2011 -0400 @@ -29,9 +29,8 @@ import java.net.URL; import java.net.URLConnection; import java.util.ArrayList; -import java.util.HashMap; import java.util.List; -import java.util.Map; +import java.util.concurrent.ConcurrentHashMap; import java.util.jar.JarOutputStream; import java.util.jar.Pack200; import java.util.jar.Pack200.Unpacker; @@ -120,8 +119,8 @@ /** resources requested to be downloaded */ private static ArrayList queue = new ArrayList(); - private static Map downloadOptions = - new HashMap(); + private static ConcurrentHashMap downloadOptions = + new ConcurrentHashMap(); /** resource trackers threads are working for (used for load balancing across multi-tracker downloads) */ private static ArrayList active = From dlila at redhat.com Tue Apr 5 09:43:37 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 5 Apr 2011 12:43:37 -0400 (EDT) Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <4D9B432D.2050202@redhat.com> Message-ID: <957962089.1960891.1302021817948.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Yes. Thank you. Denis. > Andrew. ----- Original Message ----- > On 04/05/2011 05:21 PM, Denis Lila wrote: > >> If you need the Map to be safe for concurrent access, then you > >> should > >> say so in its type, no? > > > > That's a good point. Is it ok to push after I > > change "Map" to "ConcurrentHashMap"? (I would like to avoid > > another patch for such a small change) > From dlila at redhat.com Tue Apr 5 10:22:34 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 5 Apr 2011 13:22:34 -0400 (EDT) Subject: [RFC][plugin]: part 2 of changeset 191 In-Reply-To: <991423935.1961368.1302024035415.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <351086047.1961391.1302024154819.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. In changeset 191 I replaced PluginDebug.debug(String) by PluginDebug.debug(Object...). I also changed all uses of that method to use the varargs. However, it seems I forgot to change the uses in the netscape.javascript package. The attached patch does that. Ok to push? Thank you, Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: pluginDebugUse.patch Type: text/x-patch Size: 3526 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110405/7be37d6a/pluginDebugUse.patch From dbhole at redhat.com Tue Apr 5 11:12:24 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 5 Apr 2011 14:12:24 -0400 Subject: [RFC][plugin]: part 2 of changeset 191 In-Reply-To: <351086047.1961391.1302024154819.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <991423935.1961368.1302024035415.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <351086047.1961391.1302024154819.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110405181224.GB16524@redhat.com> * Denis Lila [2011-04-05 13:23]: > Hi. > > In changeset 191 I replaced PluginDebug.debug(String) > by PluginDebug.debug(Object...). I also changed all > uses of that method to use the varargs. However, it > seems I forgot to change the uses in the netscape.javascript > package. The attached patch does that. > > Ok to push? > Yep. OK for head. Deepak > Thank you, > Denis. > diff -r 9c89214b7ef6 ChangeLog > --- a/ChangeLog Tue Apr 05 12:39:14 2011 -0400 > +++ b/ChangeLog Tue Apr 05 13:21:02 2011 -0400 > @@ -1,3 +1,9 @@ > +2011-04-05 Denis Lila > + > + * plugin/icedteanp/java/netscape/javascript/JSObject.java: > + Replaced every instance of PluginDebug.debug(a + b + c...) > + with PluginDebug.debug(a, b, c...). > + > 2011-04-05 Denis Lila > > * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > diff -r 9c89214b7ef6 plugin/icedteanp/java/netscape/javascript/JSObject.java > --- a/plugin/icedteanp/java/netscape/javascript/JSObject.java Tue Apr 05 12:39:14 2011 -0400 > +++ b/plugin/icedteanp/java/netscape/javascript/JSObject.java Tue Apr 05 13:21:02 2011 -0400 > @@ -150,10 +150,10 @@ > * Equivalent to "this.name" in JavaScript. > */ > public Object getMember(String name) { > - PluginDebug.debug("JSObject.getMember " + name); > + PluginDebug.debug("JSObject.getMember ", name); > > Object o = PluginAppletViewer.getMember(internal, name); > - PluginDebug.debug("JSObject.getMember GOT " + o); > + PluginDebug.debug("JSObject.getMember GOT ", o); > return o; > } > > @@ -163,7 +163,7 @@ > */ > // public Object getMember(int index) { return getSlot(index); } > public Object getSlot(int index) { > - PluginDebug.debug("JSObject.getSlot " + index); > + PluginDebug.debug("JSObject.getSlot ", index); > > return PluginAppletViewer.getSlot(internal, index); > } > @@ -173,7 +173,7 @@ > * Equivalent to "this.name = value" in JavaScript. > */ > public void setMember(String name, Object value) { > - PluginDebug.debug("JSObject.setMember " + name + " " + value); > + PluginDebug.debug("JSObject.setMember ", name, " ", value); > > PluginAppletViewer.setMember(internal, name, value); > } > @@ -186,7 +186,7 @@ > // setSlot(index, value); > // } > public void setSlot(int index, Object value) { > - PluginDebug.debug("JSObject.setSlot " + index + " " + value); > + PluginDebug.debug("JSObject.setSlot ", index, " ", value); > > PluginAppletViewer.setSlot(internal, index, value); > } > @@ -195,7 +195,7 @@ > * Removes a named member of a JavaScript object. > */ > public void removeMember(String name) { > - PluginDebug.debug("JSObject.removeMember " + name); > + PluginDebug.debug("JSObject.removeMember ", name); > > PluginAppletViewer.removeMember(internal, name); > } > @@ -208,9 +208,9 @@ > if (args == null) > args = new Object[0]; > > - PluginDebug.debug("JSObject.call " + methodName); > + PluginDebug.debug("JSObject.call ", methodName); > for (int i = 0; i < args.length; i++) > - PluginDebug.debug(" " + args[i]); > + PluginDebug.debug(" ", args[i]); > PluginDebug.debug(""); > return PluginAppletViewer.call(internal, methodName, args); > } > @@ -221,7 +221,7 @@ > * given by "this". > */ > public Object eval(String s) { > - PluginDebug.debug("JSObject.eval " + s); > + PluginDebug.debug("JSObject.eval ", s); > return PluginAppletViewer.eval(internal, s); > } > > @@ -246,7 +246,7 @@ > long internal = 0; > internal = ((PluginAppletViewer) > applet.getAppletContext()).getWindow(); > - PluginDebug.debug("GOT IT: " + internal); > + PluginDebug.debug("GOT IT: ", internal); > return new JSObject(internal); > } > From dlila at icedtea.classpath.org Tue Apr 5 11:34:09 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Tue, 05 Apr 2011 18:34:09 +0000 Subject: /hg/icedtea-web: Use varargs in PluginDebug.debug calls in JSObj... Message-ID: changeset eea730466b87 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=eea730466b87 author: Denis Lila date: Tue Apr 05 14:38:22 2011 -0400 Use varargs in PluginDebug.debug calls in JSObject.java. diffstat: ChangeLog | 6 +++++ plugin/icedteanp/java/netscape/javascript/JSObject.java | 20 ++++++++-------- 2 files changed, 16 insertions(+), 10 deletions(-) diffs (95 lines): diff -r 9c89214b7ef6 -r eea730466b87 ChangeLog --- a/ChangeLog Tue Apr 05 12:39:14 2011 -0400 +++ b/ChangeLog Tue Apr 05 14:38:22 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-05 Denis Lila + + * plugin/icedteanp/java/netscape/javascript/JSObject.java: + Replaced every instance of PluginDebug.debug(a + b + c...) + with PluginDebug.debug(a, b, c...). + 2011-04-05 Denis Lila * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: diff -r 9c89214b7ef6 -r eea730466b87 plugin/icedteanp/java/netscape/javascript/JSObject.java --- a/plugin/icedteanp/java/netscape/javascript/JSObject.java Tue Apr 05 12:39:14 2011 -0400 +++ b/plugin/icedteanp/java/netscape/javascript/JSObject.java Tue Apr 05 14:38:22 2011 -0400 @@ -150,10 +150,10 @@ * Equivalent to "this.name" in JavaScript. */ public Object getMember(String name) { - PluginDebug.debug("JSObject.getMember " + name); + PluginDebug.debug("JSObject.getMember ", name); Object o = PluginAppletViewer.getMember(internal, name); - PluginDebug.debug("JSObject.getMember GOT " + o); + PluginDebug.debug("JSObject.getMember GOT ", o); return o; } @@ -163,7 +163,7 @@ */ // public Object getMember(int index) { return getSlot(index); } public Object getSlot(int index) { - PluginDebug.debug("JSObject.getSlot " + index); + PluginDebug.debug("JSObject.getSlot ", index); return PluginAppletViewer.getSlot(internal, index); } @@ -173,7 +173,7 @@ * Equivalent to "this.name = value" in JavaScript. */ public void setMember(String name, Object value) { - PluginDebug.debug("JSObject.setMember " + name + " " + value); + PluginDebug.debug("JSObject.setMember ", name, " ", value); PluginAppletViewer.setMember(internal, name, value); } @@ -186,7 +186,7 @@ // setSlot(index, value); // } public void setSlot(int index, Object value) { - PluginDebug.debug("JSObject.setSlot " + index + " " + value); + PluginDebug.debug("JSObject.setSlot ", index, " ", value); PluginAppletViewer.setSlot(internal, index, value); } @@ -195,7 +195,7 @@ * Removes a named member of a JavaScript object. */ public void removeMember(String name) { - PluginDebug.debug("JSObject.removeMember " + name); + PluginDebug.debug("JSObject.removeMember ", name); PluginAppletViewer.removeMember(internal, name); } @@ -208,9 +208,9 @@ if (args == null) args = new Object[0]; - PluginDebug.debug("JSObject.call " + methodName); + PluginDebug.debug("JSObject.call ", methodName); for (int i = 0; i < args.length; i++) - PluginDebug.debug(" " + args[i]); + PluginDebug.debug(" ", args[i]); PluginDebug.debug(""); return PluginAppletViewer.call(internal, methodName, args); } @@ -221,7 +221,7 @@ * given by "this". */ public Object eval(String s) { - PluginDebug.debug("JSObject.eval " + s); + PluginDebug.debug("JSObject.eval ", s); return PluginAppletViewer.eval(internal, s); } @@ -246,7 +246,7 @@ long internal = 0; internal = ((PluginAppletViewer) applet.getAppletContext()).getWindow(); - PluginDebug.debug("GOT IT: " + internal); + PluginDebug.debug("GOT IT: ", internal); return new JSObject(internal); } From asu at redhat.com Tue Apr 5 12:20:06 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 5 Apr 2011 15:20:06 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <4D9A4B27.5040705@redhat.com> Message-ID: <1955937288.396220.1302031206910.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 04/04/2011 05:45 PM, Andrew Su wrote: > >>> I think this patch would be easier to review if you split it into > >>> two patches - one to fix problems with files being overwritten, > >>> and another to enforce cache sizes. > > I've removed the section which will ensure the cache limit. Will > > post > > that later. > > > > Thanks! > > > + /** > > + * This will return a File pointing to the location of cache item. > > + * @param urlPath Path of cache item within cache directory. > > + * @return File if we have searched before, null otherwise. > > + */ > > + private static File getCacheFileIfExist(File urlPath){ > > > Instead of nitpicking, I am going to ask you to post some information > about the files added/modified. I missed this during the original > review > (I suppose that might be a code smell and we need to do some > refactoring), but now I see that this patch introduces and/or modifies > a > number of files: RecentlyUsed, per cache-entry directory, and possibly > more metadata. Could you please describe what the overall design of > this > cache is? What data each file contains? And in what format? File: /RecentlyUsed Desc: Keep track of the most recently accessed file. It can work without this file if we traverse the directory for this information. Format: This file is kept to how a regular properties file works Key=Value The Key consist of time accessed followed by the folder number. Example: 13020173404=/4/http/www.example.come/example.jar In this case the 4 at the end is the cache directory. File: /////*.info Desc: These files contain information about the file in the directory. Such as file length(size), last-modified header from download, and whether this file should be deleted at shutdown. Format: Each line consist of a Key=Value pair to report the state of the item. The above mentioned files are the only ones that we change. Design: It works similarly to the old cache with the addition of LRU and separate per cache-entry directory. During the initialization of the resource stage (ResourceTracker.initializeResource()) Here we will try and grab the most recently downloaded version of the cache-entry. If this entry does not exist it will prepare a directory to store this item. Now, to prevent another instance of plugin/javaws from overwriting the file we lock the PropertiesFile associated with this entry. If this file does exist, but not up to date then we create a new directory to store the new file. The old entry is marked for deletion at shutdown. Onto the downloading stage. This only happens if we have found the entry to be outdated or does not exist (from above). In here we try to lock on the PropertiesFile, and block if it is either being requested, or already in downloading progress. It is okay to block here because if there is a download for this file in progress, we can't use it until it is completed anyways. Loading the jars... nothing changed here. JVM Shutdown. At this point we will remove all compressed downloads and the folders they extract to since the check for size difference will always be true, it will try to redownload anyways. This can save some space at the end of the day. After removing these entries, it will proceed to removing all folders not being tracked by RecentlyUsed. (To get rid of the currently cached items before patch). > > I would love it if the response consists of patch with a new class per > file/directory introduced/modified/repurposed and each class contains > (as comments) the purpose and format :D I've move the policy to it's own class. Where it will handle the I've refactored the managing of the LRU policy into its own class. However modifying info class will not be moved anywhere since that is already handled by CacheEntry. The directories being created didn't seem to fit to be its own class either, can not pass it onto other plugin/javaws instances without having to traverse the directories (I wanted to avoid that). Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110405_cache_v12.patch Type: text/x-patch Size: 29661 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110405/4f3c2432/20110405_cache_v12.patch From asu at redhat.com Tue Apr 5 13:27:13 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 5 Apr 2011 16:27:13 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <1872934623.115957.1300735574685.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <2072773307.397684.1302035233288.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ping. I've updated file to apply cleanly to head. Regards, Andrew ----- Original Message ----- > ----- Original Message ----- > > On 03/21/2011 02:58 PM, Andrew Su wrote: > > >> On 03/21/2011 01:51 PM, Andrew Su wrote: > > >> > > >>> v1 does not alert the user (silently ignore input). v2 alerts > > >>> the > > >>> user via popup. > > >>> > > >> > > >> Only v2 will be applied, right? > > > > > > only one of the two, was more of asking for an opinion to whether > > > we > > > want to have silent handling of the input. or nag. > > > I've fixed up v2 (now v3) assuming you wanted it to display > > > something. > > > > > > > Ah, ok. I thought v2 was an improved version of v1 (and I was > > wondering > > why you posted v1 at all). I dont really see a problem with dialogs. > > okay. > > > > > >> > > >>> 20110321_number_only_v1.patch > > >>> > > >>> > > >>> @@ -254,4 +262,28 @@ > > >>> enablePanel(panel, false); > > >>> } > > >>> } > > >>> + > > >>> + /** > > >>> + * Creates a PlainDocument that only take numbers if it will > > >>> create > > >>> a valid port number. > > >>> + * @return PlainDocument which will ensure numeric values only > > >>> and > > >>> is a valid port number. > > >>> + */ > > >>> + public static PlainDocument getNumberDocument(final Component > > >>> c){ > > >>> + return new PlainDocument(){ > > >>> + public void insertString(int offs, String str, AttributeSet a) > > >>> throws BadLocationException { > > >>> + if (str != null) { > > >>> + try { > > >>> + Integer.valueOf(str); > > >>> + int val = Integer.valueOf(this.getText(0, this.getLength()) + > > >>> str); > > >>> + if (val< 1 || val> 65535) { // Invalid port number if true > > >>> + throw new NumberFormatException("Invalid port number"); > > >>> + } > > >>> + super.insertString(offs, str, a); > > >>> + } catch (Exception e) { > > >>> + // Just don't insert. > > >>> + } > > >>> + } > > >>> + return; > > >>> + } > > >>> + }; > > >>> + } > > >> > > >> What about remove()? How is deleting port numbers handled? > > > > > > What issues do you see with removing numbers? If you are only > > > allowed to add numeric values.. > > > Removing them will still leave you with numeric values. > > > > > > > I am wondering how a port value of "" will be dealt with. > > This only controls the input, that is handled by DocumentAdapter > already. > > Regards, > Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110405_number_only_v4.patch Type: text/x-patch Size: 6805 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110405/2de8eaa4/20110405_number_only_v4.patch From omajid at redhat.com Tue Apr 5 14:01:04 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 05 Apr 2011 17:01:04 -0400 Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <2072773307.397684.1302035233288.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <2072773307.397684.1302035233288.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4D9B8310.8050201@redhat.com> On 04/05/2011 04:27 PM, Andrew Su wrote: > ping. > > I've updated file to apply cleanly to head. > > > 20110405_number_only_v4.patch > > > diff -r eea730466b87 netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java > --- a/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java Tue Apr 05 14:38:22 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java Tue Apr 05 16:26:59 2011 -0400 > @@ -114,30 +114,38 @@ > // This addresses the HTTP proxy settings. > JLabel http = new JLabel(Translator.R("APSLabelHTTP") + ":"); > final JTextField httpAddressField = new JTextField(fields[0]); > - final JTextField httpPortField = new JTextField(fields[1]); > + final JTextField httpPortField = new JTextField(); > + httpPortField.setDocument(NetworkSettingsPanel.getNumberDocument(this)); > httpAddressField.getDocument().addDocumentListener(new DocumentAdapter(fields, 0)); > httpPortField.getDocument().addDocumentListener(new DocumentAdapter(fields, 1)); > + httpPortField.setText(fields[1]); > > // This addresses the HTTPS proxy settings. > JLabel secure = new JLabel(Translator.R("APSLabelSecure") + ":"); > final JTextField secureAddressField = new JTextField(fields[2]); > - final JTextField securePortField = new JTextField(fields[3]); > + final JTextField securePortField = new JTextField(); > + securePortField.setDocument(NetworkSettingsPanel.getNumberDocument(this)); > secureAddressField.getDocument().addDocumentListener(new DocumentAdapter(fields, 2)); > securePortField.getDocument().addDocumentListener(new DocumentAdapter(fields, 3)); > + securePortField.setText(fields[3]); > > // This addresses the FTP proxy settings. > JLabel ftp = new JLabel(Translator.R("APSLabelFTP") + ":"); > final JTextField ftpAddressField = new JTextField(fields[4]); > - final JTextField ftpPortField = new JTextField(fields[5]); > + final JTextField ftpPortField = new JTextField(); > + ftpPortField.setDocument(NetworkSettingsPanel.getNumberDocument(this)); > ftpAddressField.getDocument().addDocumentListener(new DocumentAdapter(fields, 4)); > ftpPortField.getDocument().addDocumentListener(new DocumentAdapter(fields, 5)); > + ftpPortField.setText(fields[5]); > > // This addresses the Socks proxy settings. > JLabel socks = new JLabel(Translator.R("APSLabelSocks") + ":"); > final JTextField socksAddressField = new JTextField(fields[6]); > - final JTextField socksPortField = new JTextField(fields[7]); > + final JTextField socksPortField = new JTextField(); > + socksPortField.setDocument(NetworkSettingsPanel.getNumberDocument(this)); > socksAddressField.getDocument().addDocumentListener(new DocumentAdapter(fields, 6)); > socksPortField.getDocument().addDocumentListener(new DocumentAdapter(fields, 7)); > + socksPortField.setText(fields[7]); > > JCheckBox sameProxyForAll = new JCheckBox(Translator.R("APSSameProxyForAllProtocols"), Boolean.parseBoolean(fields[8])); > sameProxyForAll.addItemListener(new ItemListener() { > diff -r eea730466b87 netx/net/sourceforge/jnlp/controlpanel/NetworkSettingsPanel.java > --- a/netx/net/sourceforge/jnlp/controlpanel/NetworkSettingsPanel.java Tue Apr 05 14:38:22 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/controlpanel/NetworkSettingsPanel.java Tue Apr 05 16:26:59 2011 -0400 > @@ -21,6 +21,7 @@ > import java.awt.BorderLayout; > import java.awt.CardLayout; > import java.awt.Component; > +import java.awt.Dialog; > import java.awt.Dimension; > import java.awt.FlowLayout; > import java.awt.GridBagConstraints; > @@ -35,10 +36,15 @@ > import javax.swing.ButtonGroup; > import javax.swing.JButton; > import javax.swing.JCheckBox; > +import javax.swing.JDialog; > import javax.swing.JLabel; > +import javax.swing.JOptionPane; > import javax.swing.JPanel; > import javax.swing.JRadioButton; > import javax.swing.JTextField; > +import javax.swing.text.AttributeSet; > +import javax.swing.text.BadLocationException; > +import javax.swing.text.PlainDocument; > > import net.sourceforge.jnlp.config.DeploymentConfiguration; > import net.sourceforge.jnlp.runtime.Translator; > @@ -113,8 +119,10 @@ > final JTextField addressField = new JTextField(config.getProperty(properties[1]), 10); > addressField.getDocument().addDocumentListener(new DocumentAdapter(config, properties[1])); > > - final JTextField portField = new JTextField(config.getProperty(properties[2]), 3); > + final JTextField portField = new JTextField(5); > + portField.setDocument(NetworkSettingsPanel.getNumberDocument(this)); > portField.getDocument().addDocumentListener(new DocumentAdapter(config, properties[2])); > + portField.setText(config.getProperty(properties[2])); > > // Create the button which allows setting of other types of proxy. > JButton advancedProxyButton = new JButton(Translator.R("NSAdvanced") + "..."); > @@ -254,4 +262,29 @@ > enablePanel(panel, false); > } > } > + > + /** > + * Creates a PlainDocument that only take numbers if it will create a valid port number. > + * @return PlainDocument which will ensure numeric values only and is a valid port number. > + */ > + public static PlainDocument getNumberDocument(final Component c){ Hm... what is c? Is it used in this method? If it's something left over from a previous patch, it might be best just to delete it. I would also prefer it if the method name indicated that it's meant for port numbers, not general numbers. > + return new PlainDocument(){ > + public void insertString(int offs, String str, AttributeSet a) throws BadLocationException { > + if (str != null) { > + try { > + Integer.valueOf(str); > + int val = Integer.valueOf(this.getText(0, this.getLength()) + str); > + if (val< 1 || val> 65535) { // Invalid port number if true > + throw new NumberFormatException("Invalid port number"); > + } > + super.insertString(offs, str, a); > + } catch (Exception e) { > + JOptionPane.showMessageDialog(null, Translator.R("CPInvalidPort"), Translator.R("CPInvalidPortTitle") > + , JOptionPane.WARNING_MESSAGE); > + } > + } > + return; > + } > + }; > + } > } > diff -r eea730466b87 netx/net/sourceforge/jnlp/resources/Messages.properties > --- a/netx/net/sourceforge/jnlp/resources/Messages.properties Tue Apr 05 14:38:22 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties Tue Apr 05 16:26:59 2011 -0400 > @@ -407,6 +407,8 @@ > > # Control Panel - Misc. > CPJRESupport=IcedTea-Web currently does not support the use of multiple JREs. > +CPInvalidPort=Invalid port number given.\n[Valid port numbers are 1-65535] > +CPInvalidPortTitle=Error on input. > > # command line control panel > CLNoInfo=No information avaiable (is this a valid option?). Everything else looks fine. Cheers, Omair From omajid at redhat.com Tue Apr 5 15:43:09 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 05 Apr 2011 18:43:09 -0400 Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1955937288.396220.1302031206910.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1955937288.396220.1302031206910.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4D9B9AFD.1040506@redhat.com> On 04/05/2011 03:20 PM, Andrew Su wrote: Thanks for the explanations! > File: > /RecentlyUsed > Desc: > Keep track of the most recently accessed file. It can work without > this file if we traverse the directory for this information. > Format: > This file is kept to how a regular properties file works > Key=Value > The Key consist of time accessed followed by the folder number. > Example: > 13020173404=/4/http/www.example.come/example.jar > In this case the 4 at the end is the cache directory. > From reading the previous patch, I gather that the example should be 13020173404/4/http/www.example.come/example.jar=/4/http/www.example.come/example.jar. Is that right? > > File: > /////*.info > Desc: > These files contain information about the file in the directory. > Such as file length(size), last-modified header from download, and > whether this file should be deleted at shutdown. > Format: > Each line consist of a Key=Value pair to report the state of the > item. > Ah, I see. The versioning is a little strange and might make grepping a little harder. But I suppose it makes sense. > > The above mentioned files are the only ones that we change. > > Design: > It works similarly to the old cache with the addition of LRU and > separate per cache-entry directory. > During the initialization of the resource stage > (ResourceTracker.initializeResource()) Here we will try and grab > the most recently downloaded version of the cache-entry. If this > entry does not exist it will prepare a directory to store this > item. Now, to prevent another instance of plugin/javaws from > overwriting the file we lock the PropertiesFile associated with > this entry. If this file does exist, but not up to date then we > create a new directory to store the new file. The old entry is > marked for deletion at shutdown. > Isn't this susceptible to race conditions? Suppose javaws process A starts and downloads http://example.com/example.jar. Then process B starts and downloads an updated version of http://example.com/example.jar. Process B will mark process A's file as ready for deletion right? If process B shuts down first (before A shuts down) then B will delete A's jars. > Onto the downloading stage. This only happens if we have found > the entry to be outdated or does not exist (from above). In here > we try to lock on the PropertiesFile, and block if it is either > being requested, or already in downloading progress. It is okay > to block here because if there is a download for this file in > progress, we can't use it until it is completed anyways. > > Loading the jars... nothing changed here. > > JVM Shutdown. At this point we will remove all compressed > downloads and the folders they extract to since the check for > size difference will always be true, it will try to redownload > anyways. This can save some space at the end of the day. > After removing these entries, it will proceed to removing all > folders not being tracked by RecentlyUsed. (To get rid of the > currently cached items before patch). > >> > >> > I would love it if the response consists of patch with a new class per >> > file/directory introduced/modified/repurposed and each class contains >> > (as comments) the purpose and format :D > I've move the policy to it's own class. Where it will handle the > > I've refactored the managing of the LRU policy into its own class. > However modifying info class will not be moved anywhere since that > is already handled by CacheEntry. The directories being created > didn't seem to fit to be its own class either, can not pass it > onto other plugin/javaws instances without having to traverse > the directories (I wanted to avoid that). > I have left a few comments in-line, but we really should sort out the overall design (and any possible issues with it) before doing code reviews. > Cheers, > Andrew > > > 20110405_cache_v12.patch > > > diff -r eea730466b87 ChangeLog > --- a/ChangeLog Tue Apr 05 14:38:22 2011 -0400 > +++ b/ChangeLog Tue Apr 05 15:21:46 2011 -0400 > @@ -1,3 +1,26 @@ > +2011-04-05 Andrew Su > + > + * netx/net/sourceforge/jnlp/cache/CacheEntry.java: > + (markForDelete, lock, unlock): New methods. > + * netx/net/sourceforge/jnlp/cache/CacheUtil.java: > + (getCacheFile): Changed to look for most recently used item, and when > + not found create a new entry. > + (makeNewCacheFile, lockFile, unlockFile, removeUntrackedDirectories, > + cleanCache, getCacheFileIfExist): new methods. > + * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > + (downloadResource): Changed to wait if we are already downloading the > + file. If file downloaded is compressed, mark compressed and extracted > + files for delete at shutdown. > + (initializeResource): Added checks for when the cache needs updating > + to create new folder entry. > + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: > + (JNLPClassLoader): Change order so that we get resources first then > + check permissions for the jars. > + * netx/net/sourceforge/jnlp/util/FileUtils.java: > + (getFileLock): New method. > + * netx/net/sourceforge/jnlp/cache/CacheLRUPolicy.java: New class. > + This class handles the sorting of items when they are set to update. > + > 2011-04-05 Denis Lila > > * plugin/icedteanp/java/netscape/javascript/JSObject.java: > diff -r eea730466b87 netx/net/sourceforge/jnlp/cache/CacheEntry.java > --- a/netx/net/sourceforge/jnlp/cache/CacheEntry.java Tue Apr 05 14:38:22 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheEntry.java Tue Apr 05 15:21:46 2011 -0400 > @@ -162,4 +162,25 @@ > properties.store(); > } > > + /** > + * Mark this entry for deletion at shutdown. > + */ > + public void markForDelete() { // once marked it should not be unmarked. > + properties.setProperty("delete", Boolean.toString(true)); > + } > + > + /** > + * Lock cache item. > + */ > + protected void lock() { > + CacheUtil.lockFile(properties); > + } > + > + /** > + * Unlock cache item. > + */ > + protected void unlock() { > + CacheUtil.unlockFile(properties); > + } > + > } > diff -r eea730466b87 netx/net/sourceforge/jnlp/cache/CacheLRUPolicy.java > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUPolicy.java Tue Apr 05 15:21:46 2011 -0400 > @@ -0,0 +1,179 @@ Please add a license header to this file. > +package net.sourceforge.jnlp.cache; > + > + > +/** > + * This class helps maintain the ordering of most recently use items across > + * multiple jvm instances. > + * > + * @author Andrew Su (asu at redhat.com,andrew.su at utoronto.ca) > + * > + */ > +public class CacheLRUPolicy { > + I thought a cache replacement policy class will specify which entries (or files) to keep (or remove) given a set of constraints. This class looks more like another cache class. I suppose it's great to have a wrapper class to parse/update the cache metadata, but calling it a policy might be a little misleading. > + /* lock for the file RecentlyUsed */ > + private static FileLock fl = null; > + > + /* location of cache directory */ > + private static final String cacheDir = new File(JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)).getPath(); > + > + /** > + * This adds a new entry to file. > + * > + * @param identifier value to append to key. > + * @param path path to cache item. > + * @return true if we successfully added to map, false otherwise. > + */ > + public synchronized boolean addEntry(String identifier, String path) { > + String key = Long.toString(System.currentTimeMillis()) + identifier; > + if (cacheOrder.containsKey(key)) return false; > + cacheOrder.setProperty(key, path); > + return true; > + } > + > + /** > + * This removed an entry from our map. > + * > + * @param key key we want to remove. > + * @return true if we successfully removed key from map, false otherwise. > + */ > + public synchronized boolean removeEntry(String key) { > + if (!cacheOrder.containsKey(key)) return false; > + cacheOrder.remove(key); > + return true; > + } > + > + /** > + * This updates the given key to reflect it was recently accessed. > + * > + * @param oldKey Key we wish to update. > + * @return true if we successfully updated value, false otherwise. > + */ > + public synchronized boolean updateEntry(String oldKey) { > + if (!cacheOrder.containsKey(oldKey)) return false; > + String value = cacheOrder.getProperty(oldKey); > + > + String str = cacheOrder.getProperty(oldKey); > + str = str.substring(cacheDir.length()); > + int index = str.indexOf(File.separatorChar, 1); > + String folder = str.substring(1, index); > + > + cacheOrder.remove(oldKey); > + cacheOrder.setProperty(Long.toString(System.currentTimeMillis()) + folder, value); > + return true; > + } > + I like how we have similar methods - addEntry/updateEntry/removeEntry. But their arguments are not consistent at all. Remove and update expect keys, but add only expects an identifier. > + /** > + * Lock the file to have exclusive access. > + */ > + public synchronized void lock() { > + try { > + File f = new File(cacheOrder.getStoreFile().getPath()); > + if (!f.exists()) { > + FileUtils.createParentDir(f); > + FileUtils.createRestrictedFile(f, true); > + } > + fl = FileUtils.getFileLock(f.getPath(), false, true); > + } catch (OverlappingFileLockException e) { // if overlap we just increase the count. > + } catch (Exception e) { // We didn't get a lock.. > + e.printStackTrace(); > + } > + if (fl != null) lockCount++; > + } > + > + /** > + * Unlock the file. > + */ > + public synchronized void unlock() { > + if (fl != null) { > + lockCount--; > + try { > + if (lockCount == 0) { > + fl.release(); > + fl.channel().close(); > + fl = null; > + } > + } catch (IOException e) { > + e.printStackTrace(); > + } > + } > + } > + The locks ensure ordering between processes so we still need another set of locks to ensure consistency within the same process. Perhaps you might also want to acquire a java.util.concurrent.locks.Lock here? > + public synchronized String getValue(String key) { > + return cacheOrder.getProperty(key); > + } > + A more descriptive name for this method might be more appropriate. > diff -r eea730466b87 netx/net/sourceforge/jnlp/cache/CacheUtil.java > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Tue Apr 05 14:38:22 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Tue Apr 05 15:21:46 2011 -0400 > @@ -39,6 +42,18 @@ > */ > public class CacheUtil { > > + private static final String cacheDir = new File(JNLPRuntime.getConfiguration().getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)).getPath(); // Do this with file to standardize it. > + Please try to keep lines to 80 chars. Also, please try and use UPPER_CASE_VARIABLE_NAME for constants. > - } catch (Exception ex) { > - if (JNLPRuntime.isDebug()) > - ex.printStackTrace(); > + // We need to reload the cacheOrder file each time > + // since another plugin/javaws instance may have updated it. > + policy.load(); > + cacheFile = getCacheFileIfExist(urlToPath(source, "")); I wonder how other methods that use urlToPath work with the new cache location... > diff -r eea730466b87 netx/net/sourceforge/jnlp/cache/ResourceTracker.java > --- a/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Tue Apr 05 14:38:22 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Tue Apr 05 15:21:46 2011 -0400 > + if (!downloadLocationFile.exists()) { > + while (-1 != (rlen = in.read(buf))) { > + resource.transferred += rlen; > + out.write(buf, 0, rlen); > } resource.transferred is never updated if the download file already exists. Perhaps you might want to bump it at the end? I am not sure how it interacts with progress indicators at this point. From adalbert.prokop at gmx.de Wed Apr 6 00:06:10 2011 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Wed, 06 Apr 2011 09:06:10 +0200 Subject: Question about IcedTea6 1.9.7 + Webstart (NetX) + OSGI Message-ID: <4D9C10E2.1040000@gmx.de> Hello! I've got a problem (and possibly a bug to report) with IcedTea6 1.9.7 using Webstart (NetX) and OSGI. Basically, calling BasicService.getCodeBase() always returns null if a webstart application uses OSGI. Sun/Oracle's implementation behaves differently, they return the code base as defined in the JNLP file. I suspect the problem in the method JNLPSecurityManager. getApplication(Class[], int). The code iterates over all classes on the stack, retrieving their class loaders and checking their types. But in case of OSGI the method getClassLoader() will return null. Is this worth a bug entry? -- Best wishes, Adalbert From ptisnovs at redhat.com Wed Apr 6 00:58:47 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Wed, 06 Apr 2011 09:58:47 +0200 Subject: Various backports for IcedTea6-1.8, IcedTea6-1.9 and IcedTea6-1.10 Message-ID: <4D9C1D37.6020800@redhat.com> Hi Andrew, could you please review backports I made for IcedTea6-1.8 and IcedTea6-1.9: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/013316.html I'd also like to have this backports for IcedTea6-1.10 reviewed, could you please do that?: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013377.html Thank you VM in advance Pavel From aph at redhat.com Wed Apr 6 01:40:54 2011 From: aph at redhat.com (Andrew Haley) Date: Wed, 06 Apr 2011 09:40:54 +0100 Subject: Question about IcedTea6 1.9.7 + Webstart (NetX) + OSGI In-Reply-To: <4D9C10E2.1040000@gmx.de> References: <4D9C10E2.1040000@gmx.de> Message-ID: <4D9C2716.4080603@redhat.com> On 06/04/11 08:06, Adalbert Prokop wrote: > Hello! > > I've got a problem (and possibly a bug to report) with IcedTea6 1.9.7 > using Webstart (NetX) and OSGI. > Basically, calling BasicService.getCodeBase() always returns null if a > webstart application uses OSGI. > > Sun/Oracle's implementation behaves differently, they return the code > base as defined in the JNLP file. > > I suspect the problem in the method JNLPSecurityManager. > getApplication(Class[], int). The code iterates over all classes on the > stack, retrieving their class loaders and checking their types. But in > case of OSGI the method getClassLoader() will return null. > > Is this worth a bug entry? Yes. Please make sure the bug report contains a full test case. Andrew. From asu at redhat.com Wed Apr 6 06:25:29 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 6 Apr 2011 09:25:29 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <4D9B8310.8050201@redhat.com> Message-ID: <2122402386.407203.1302096329525.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> --snip-- > > @@ -254,4 +262,29 @@ > > enablePanel(panel, false); > > } > > } > > + > > + /** > > + * Creates a PlainDocument that only take numbers if it will create > > a valid port number. > > + * @return PlainDocument which will ensure numeric values only and > > is a valid port number. > > + */ > > + public static PlainDocument getNumberDocument(final Component c){ > > Hm... what is c? Is it used in this method? If it's something left > over > from a previous patch, it might be best just to delete it. I would > also > prefer it if the method name indicated that it's meant for port > numbers, > not general numbers. > > > + return new PlainDocument(){ > > + public void insertString(int offs, String str, AttributeSet a) > > throws BadLocationException { > > + if (str != null) { > > + try { > > + Integer.valueOf(str); > > + int val = Integer.valueOf(this.getText(0, this.getLength()) + > > str); > > + if (val< 1 || val> 65535) { // Invalid port number if true > > + throw new NumberFormatException("Invalid port number"); > > + } > > + super.insertString(offs, str, a); > > + } catch (Exception e) { > > + JOptionPane.showMessageDialog(null, Translator.R("CPInvalidPort"), > > Translator.R("CPInvalidPortTitle") > > + , JOptionPane.WARNING_MESSAGE); > > + } > > + } > > + return; > > + } > > + }; > > + } > > } > > diff -r eea730466b87 > > netx/net/sourceforge/jnlp/resources/Messages.properties > > --- a/netx/net/sourceforge/jnlp/resources/Messages.properties Tue > > Apr 05 14:38:22 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties Tue > > Apr 05 16:26:59 2011 -0400 > > @@ -407,6 +407,8 @@ > > > > # Control Panel - Misc. > > CPJRESupport=IcedTea-Web currently does not support the use of > > multiple JREs. > > +CPInvalidPort=Invalid port number given.\n[Valid port numbers are > > 1-65535] > > +CPInvalidPortTitle=Error on input. > > > > # command line control panel > > CLNoInfo=No information avaiable (is this a valid option?). > > Everything else looks fine. Thanks for looking it over, I've attached a version with the extra parameter removed and renamed it to getPortNumberDocument. Cheers, Andrew From asu at redhat.com Wed Apr 6 06:25:53 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 6 Apr 2011 09:25:53 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <2122402386.407203.1302096329525.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <543054304.407226.1302096353392.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> And here is the file.. ----- Original Message ----- > --snip-- > > > > @@ -254,4 +262,29 @@ > > > enablePanel(panel, false); > > > } > > > } > > > + > > > + /** > > > + * Creates a PlainDocument that only take numbers if it will > > > create > > > a valid port number. > > > + * @return PlainDocument which will ensure numeric values only > > > and > > > is a valid port number. > > > + */ > > > + public static PlainDocument getNumberDocument(final Component > > > c){ > > > > Hm... what is c? Is it used in this method? If it's something left > > over > > from a previous patch, it might be best just to delete it. I would > > also > > prefer it if the method name indicated that it's meant for port > > numbers, > > not general numbers. > > > > > + return new PlainDocument(){ > > > + public void insertString(int offs, String str, AttributeSet a) > > > throws BadLocationException { > > > + if (str != null) { > > > + try { > > > + Integer.valueOf(str); > > > + int val = Integer.valueOf(this.getText(0, this.getLength()) + > > > str); > > > + if (val< 1 || val> 65535) { // Invalid port number if true > > > + throw new NumberFormatException("Invalid port number"); > > > + } > > > + super.insertString(offs, str, a); > > > + } catch (Exception e) { > > > + JOptionPane.showMessageDialog(null, > > > Translator.R("CPInvalidPort"), > > > Translator.R("CPInvalidPortTitle") > > > + , JOptionPane.WARNING_MESSAGE); > > > + } > > > + } > > > + return; > > > + } > > > + }; > > > + } > > > } > > > diff -r eea730466b87 > > > netx/net/sourceforge/jnlp/resources/Messages.properties > > > --- a/netx/net/sourceforge/jnlp/resources/Messages.properties Tue > > > Apr 05 14:38:22 2011 -0400 > > > +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties Tue > > > Apr 05 16:26:59 2011 -0400 > > > @@ -407,6 +407,8 @@ > > > > > > # Control Panel - Misc. > > > CPJRESupport=IcedTea-Web currently does not support the use of > > > multiple JREs. > > > +CPInvalidPort=Invalid port number given.\n[Valid port numbers are > > > 1-65535] > > > +CPInvalidPortTitle=Error on input. > > > > > > # command line control panel > > > CLNoInfo=No information avaiable (is this a valid option?). > > > > Everything else looks fine. > > Thanks for looking it over, I've attached a version with the extra > parameter removed and renamed it to getPortNumberDocument. > > Cheers, > Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110405_number_only_v5.patch Type: text/x-patch Size: 6504 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110406/a1239cdd/20110405_number_only_v5.patch From omajid at redhat.com Wed Apr 6 06:30:37 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 06 Apr 2011 09:30:37 -0400 Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <543054304.407226.1302096353392.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <543054304.407226.1302096353392.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4D9C6AFD.4060605@redhat.com> On 04/06/2011 09:25 AM, Andrew Su wrote: > And here is the file.. >> Thanks for looking it over, I've attached a version with the extra >> parameter removed and renamed it to getPortNumberDocument. Looks good to me. Ok for HEAD. Cheers, Omair From asu at icedtea.classpath.org Wed Apr 6 07:00:45 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Wed, 06 Apr 2011 14:00:45 +0000 Subject: /hg/icedtea-web: Restrict port fields in itw-settings to accept ... Message-ID: changeset 24f034f372e4 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=24f034f372e4 author: Andrew Su date: Wed Apr 06 10:02:46 2011 -0400 Restrict port fields in itw-settings to accept only valid port numbers. diffstat: ChangeLog | 11 +++ netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java | 16 +++- netx/net/sourceforge/jnlp/controlpanel/NetworkSettingsPanel.java | 33 +++++++++- netx/net/sourceforge/jnlp/resources/Messages.properties | 2 + 4 files changed, 57 insertions(+), 5 deletions(-) diffs (135 lines): diff -r eea730466b87 -r 24f034f372e4 ChangeLog --- a/ChangeLog Tue Apr 05 14:38:22 2011 -0400 +++ b/ChangeLog Wed Apr 06 10:02:46 2011 -0400 @@ -1,3 +1,14 @@ +2011-04-06 Andrew Su + + * netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java: + (addComponents): Changed all port fields to use document which + prevents input of non-valid port numbers. + * netx/net/sourceforge/jnlp/controlpanel/NetworkSettingsPanel.java: + (addComponents): likewise. + (getPortNumberDocument): New method. + * netx/net/sourceforge/jnlp/resources/Messages.properties: + Added CPInvalidPort and CPInvalidPortTitle. + 2011-04-05 Denis Lila * plugin/icedteanp/java/netscape/javascript/JSObject.java: diff -r eea730466b87 -r 24f034f372e4 netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java --- a/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java Tue Apr 05 14:38:22 2011 -0400 +++ b/netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java Wed Apr 06 10:02:46 2011 -0400 @@ -114,30 +114,38 @@ // This addresses the HTTP proxy settings. JLabel http = new JLabel(Translator.R("APSLabelHTTP") + ":"); final JTextField httpAddressField = new JTextField(fields[0]); - final JTextField httpPortField = new JTextField(fields[1]); + final JTextField httpPortField = new JTextField(); + httpPortField.setDocument(NetworkSettingsPanel.getPortNumberDocument()); httpAddressField.getDocument().addDocumentListener(new DocumentAdapter(fields, 0)); httpPortField.getDocument().addDocumentListener(new DocumentAdapter(fields, 1)); + httpPortField.setText(fields[1]); // This addresses the HTTPS proxy settings. JLabel secure = new JLabel(Translator.R("APSLabelSecure") + ":"); final JTextField secureAddressField = new JTextField(fields[2]); - final JTextField securePortField = new JTextField(fields[3]); + final JTextField securePortField = new JTextField(); + securePortField.setDocument(NetworkSettingsPanel.getPortNumberDocument()); secureAddressField.getDocument().addDocumentListener(new DocumentAdapter(fields, 2)); securePortField.getDocument().addDocumentListener(new DocumentAdapter(fields, 3)); + securePortField.setText(fields[3]); // This addresses the FTP proxy settings. JLabel ftp = new JLabel(Translator.R("APSLabelFTP") + ":"); final JTextField ftpAddressField = new JTextField(fields[4]); - final JTextField ftpPortField = new JTextField(fields[5]); + final JTextField ftpPortField = new JTextField(); + ftpPortField.setDocument(NetworkSettingsPanel.getPortNumberDocument()); ftpAddressField.getDocument().addDocumentListener(new DocumentAdapter(fields, 4)); ftpPortField.getDocument().addDocumentListener(new DocumentAdapter(fields, 5)); + ftpPortField.setText(fields[5]); // This addresses the Socks proxy settings. JLabel socks = new JLabel(Translator.R("APSLabelSocks") + ":"); final JTextField socksAddressField = new JTextField(fields[6]); - final JTextField socksPortField = new JTextField(fields[7]); + final JTextField socksPortField = new JTextField(); + socksPortField.setDocument(NetworkSettingsPanel.getPortNumberDocument()); socksAddressField.getDocument().addDocumentListener(new DocumentAdapter(fields, 6)); socksPortField.getDocument().addDocumentListener(new DocumentAdapter(fields, 7)); + socksPortField.setText(fields[7]); JCheckBox sameProxyForAll = new JCheckBox(Translator.R("APSSameProxyForAllProtocols"), Boolean.parseBoolean(fields[8])); sameProxyForAll.addItemListener(new ItemListener() { diff -r eea730466b87 -r 24f034f372e4 netx/net/sourceforge/jnlp/controlpanel/NetworkSettingsPanel.java --- a/netx/net/sourceforge/jnlp/controlpanel/NetworkSettingsPanel.java Tue Apr 05 14:38:22 2011 -0400 +++ b/netx/net/sourceforge/jnlp/controlpanel/NetworkSettingsPanel.java Wed Apr 06 10:02:46 2011 -0400 @@ -36,9 +36,13 @@ import javax.swing.JButton; import javax.swing.JCheckBox; import javax.swing.JLabel; +import javax.swing.JOptionPane; import javax.swing.JPanel; import javax.swing.JRadioButton; import javax.swing.JTextField; +import javax.swing.text.AttributeSet; +import javax.swing.text.BadLocationException; +import javax.swing.text.PlainDocument; import net.sourceforge.jnlp.config.DeploymentConfiguration; import net.sourceforge.jnlp.runtime.Translator; @@ -113,8 +117,10 @@ final JTextField addressField = new JTextField(config.getProperty(properties[1]), 10); addressField.getDocument().addDocumentListener(new DocumentAdapter(config, properties[1])); - final JTextField portField = new JTextField(config.getProperty(properties[2]), 3); + final JTextField portField = new JTextField(5); + portField.setDocument(NetworkSettingsPanel.getPortNumberDocument()); portField.getDocument().addDocumentListener(new DocumentAdapter(config, properties[2])); + portField.setText(config.getProperty(properties[2])); // Create the button which allows setting of other types of proxy. JButton advancedProxyButton = new JButton(Translator.R("NSAdvanced") + "..."); @@ -254,4 +260,29 @@ enablePanel(panel, false); } } + + /** + * Creates a PlainDocument that only take numbers if it will create a valid port number. + * @return PlainDocument which will ensure numeric values only and is a valid port number. + */ + public static PlainDocument getPortNumberDocument(){ + return new PlainDocument(){ + public void insertString(int offs, String str, AttributeSet a) throws BadLocationException { + if (str != null) { + try { + Integer.valueOf(str); + int val = Integer.valueOf(this.getText(0, this.getLength()) + str); + if (val < 1 || val > 65535) { // Invalid port number if true + throw new NumberFormatException("Invalid port number"); + } + super.insertString(offs, str, a); + } catch (Exception e) { + JOptionPane.showMessageDialog(null, Translator.R("CPInvalidPort"), Translator.R("CPInvalidPortTitle") + , JOptionPane.WARNING_MESSAGE); + } + } + return; + } + }; + } } diff -r eea730466b87 -r 24f034f372e4 netx/net/sourceforge/jnlp/resources/Messages.properties --- a/netx/net/sourceforge/jnlp/resources/Messages.properties Tue Apr 05 14:38:22 2011 -0400 +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties Wed Apr 06 10:02:46 2011 -0400 @@ -407,6 +407,8 @@ # Control Panel - Misc. CPJRESupport=IcedTea-Web currently does not support the use of multiple JREs. +CPInvalidPort=Invalid port number given.\n[Valid port numbers are 1-65535] +CPInvalidPortTitle=Error on input. # command line control panel CLNoInfo=No information avaiable (is this a valid option?). From asu at redhat.com Wed Apr 6 07:02:23 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 6 Apr 2011 10:02:23 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <4D9C6AFD.4060605@redhat.com> Message-ID: <217697480.409003.1302098543967.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 04/06/2011 09:25 AM, Andrew Su wrote: > > And here is the file.. > > >> Thanks for looking it over, I've attached a version with the extra > >> parameter removed and renamed it to getPortNumberDocument. > > Looks good to me. Ok for HEAD. Thanks for review, pushed. Cheers, Andrew From dlila at redhat.com Wed Apr 6 07:52:20 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 6 Apr 2011 10:52:20 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1955937288.396220.1302031206910.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1592863020.2018211.1302101540485.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Andrew. I've been looking over this. Rather than saying what I don't like, I committed your patch to a local repository and changed whatever I didn't like. It's much easier to express what changes I would like to see in Java than in English ;-). I've attached the patch with my changes, so in this e-mail I'll just give reasons for those changes. A lot of it is pretty minor things (like turning "if (e) return false;" into "if (e)\n return false"). Feel free to ignore those stylistic kind of changes. The other changes are: Adding a "," between the time and the folder identifier in the RecentlyUsed file. CacheLRUPolicy: enums are better for singletons. Also, if we have a singleton it's not so good to have many static fields because if ever we needed more than one instance of that class, the synchronized access to the static data structures would break. CacheLRUPolicy.updateEntry: the changes here save us a "substring" call, and it's slightly easier to read. getSortedKeys is now called getLRUSortedEntries. This was the biggest change and the reasons for it were: 1) We already have enough map iterations of the form: for key in keyset: value = map.getvalue(key) We shouldn't add to these. Iterating over (key, value) entries is better. 2) It's better to return the entries in the order that we want to use them, rather than iterating backwards. 3) We want to sort by the last updated time, so it's a good idea to turn the strings into longs first. Comparing strings might be correct (for now), but it's only correct by coincidence, and that should be avoided. Regards, Denis. ----- Original Message ----- > ----- Original Message ----- > > On 04/04/2011 05:45 PM, Andrew Su wrote: > > >>> I think this patch would be easier to review if you split it > > >>> into > > >>> two patches - one to fix problems with files being overwritten, > > >>> and another to enforce cache sizes. > > > I've removed the section which will ensure the cache limit. Will > > > post > > > that later. > > > > > > > Thanks! > > > > > + /** > > > + * This will return a File pointing to the location of cache > > > item. > > > + * @param urlPath Path of cache item within cache directory. > > > + * @return File if we have searched before, null otherwise. > > > + */ > > > + private static File getCacheFileIfExist(File urlPath){ > > > > > > Instead of nitpicking, I am going to ask you to post some > > information > > about the files added/modified. I missed this during the original > > review > > (I suppose that might be a code smell and we need to do some > > refactoring), but now I see that this patch introduces and/or > > modifies > > a > > number of files: RecentlyUsed, per cache-entry directory, and > > possibly > > more metadata. Could you please describe what the overall design of > > this > > cache is? What data each file contains? And in what format? > > File: > /RecentlyUsed > Desc: > Keep track of the most recently accessed file. It can work without > this file if we traverse the directory for this information. > Format: > This file is kept to how a regular properties file works > Key=Value > The Key consist of time accessed followed by the folder number. > Example: > 13020173404=/4/http/www.example.come/example.jar > In this case the 4 at the end is the cache directory. > > > File: > /////*.info > Desc: > These files contain information about the file in the directory. > Such as file length(size), last-modified header from download, and > whether this file should be deleted at shutdown. > Format: > Each line consist of a Key=Value pair to report the state of the > item. > > > The above mentioned files are the only ones that we change. > > Design: > It works similarly to the old cache with the addition of LRU and > separate per cache-entry directory. > During the initialization of the resource stage > (ResourceTracker.initializeResource()) Here we will try and grab > the most recently downloaded version of the cache-entry. If this > entry does not exist it will prepare a directory to store this > item. Now, to prevent another instance of plugin/javaws from > overwriting the file we lock the PropertiesFile associated with > this entry. If this file does exist, but not up to date then we > create a new directory to store the new file. The old entry is > marked for deletion at shutdown. > > Onto the downloading stage. This only happens if we have found > the entry to be outdated or does not exist (from above). In here > we try to lock on the PropertiesFile, and block if it is either > being requested, or already in downloading progress. It is okay > to block here because if there is a download for this file in > progress, we can't use it until it is completed anyways. > > Loading the jars... nothing changed here. > > JVM Shutdown. At this point we will remove all compressed > downloads and the folders they extract to since the check for > size difference will always be true, it will try to redownload > anyways. This can save some space at the end of the day. > After removing these entries, it will proceed to removing all > folders not being tracked by RecentlyUsed. (To get rid of the > currently cached items before patch). > > > > > I would love it if the response consists of patch with a new class > > per > > file/directory introduced/modified/repurposed and each class > > contains > > (as comments) the purpose and format :D > > I've move the policy to it's own class. Where it will handle the > > I've refactored the managing of the LRU policy into its own class. > However modifying info class will not be moved anywhere since that > is already handled by CacheEntry. The directories being created > didn't seem to fit to be its own class either, can not pass it > onto other plugin/javaws instances without having to traverse > the directories (I wanted to avoid that). > > Cheers, > Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: myMods.patch Type: text/x-patch Size: 11859 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110406/a72a9a5e/myMods.patch From dlila at redhat.com Wed Apr 6 09:50:32 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 6 Apr 2011 12:50:32 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1592863020.2018211.1302101540485.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <212459532.2020829.1302108632117.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi again. My previous e-mail was mostly just low level implementation comments. I have only one problem with the design: right now our cache management metadata is stored in RecentlyUsed which is a map. Storing information about the time of last update of a cached resource using the time as a key seems very unnatural to me. Right now, CacheLRUPolicy.cacheOrder isn't really a hash map at all. It's just a list of couples because every time we read from it we start out with the name and try to read the time. In other words, given the value we try to read the key. That is very backwards for a hash map, which is supposed to provide the value given the key. If we could somehow make the resource that we're caching the key and the time of last update the value, I think that would simplify things a lot. In particular we might be able to entirely get rid of these identifiers that we're adding to folder names and times. And also checking whether something is in the cache and updating it should be made much simpler (no loops would be required). What do you think? Regards, Denis. ----- Original Message ----- > Hi Andrew. > > I've been looking over this. Rather than saying what I > don't like, I committed your patch to a local repository > and changed whatever I didn't like. It's much easier to ... From suenaga.yasumasa at oss.ntt.co.jp Thu Apr 7 00:24:39 2011 From: suenaga.yasumasa at oss.ntt.co.jp (Yasumasa Suenaga) Date: Thu, 07 Apr 2011 16:24:39 +0900 Subject: JNI functions "CallNonvirtual*" probe is incorrect Message-ID: <4D9D66B7.7060803@oss.ntt.co.jp> Hi, I've tried to test my program with SystemTap. When I probed CallNonvirtualVoidMethod(), I seem to get incorrect value through "hotspot_jni.stp". My test program result(attached it to this email: test.tar.gz) as following: ------------ [root at RHEL6 nonvirtual]# gcc -shared -fPIC -I$JAVA_HOME/include -I$JAVA_HOME/include/linux -o libnonvirtual.so jni.c [root at RHEL6 nonvirtual]# javac Main.java [root at RHEL6 nonvirtual]# stap -c 'java -Djava.library.path=. Main' ../tapset/jnifunc.stp from JNI: env = 0x7fb99c0071b8, obj = 0x7fb9a0d638c0, clazz = 0x7fb99c068950, methodID = 0x9c064290 from CallStub! CallNonvirtualVoidMethod(env=0x7fb99c0071b8,obj=0x7fb9a0d638c0,methodid=0x7fb99c068950), arg4=0x7fb99c064290 ------------ "from ..." is printed from JNI code. "CallNonvirtualVoidMethod( ..." is printed from SystemTap probepoint (through "probestr"). "clazz" does not exist in hotspot_jni.stp, and methodid points clazz. In HotSpot source code (hotspot/src/share/vm/prims/jni.cpp) defines CallNonvirtual functions as folllowing: ------------ #define DEFINE_CALLNONVIRTUALMETHOD(ResultType, Result, Tag) \ \ DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##Method, ResultType);\ DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##MethodV, ResultType);\ DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##MethodA, ResultType);\ \ JNI_ENTRY(ResultType, \ jni_CallNonvirtual##Result##Method(JNIEnv *env, jobject obj, jclass cls, jmethodID methodID, ...)) \ JNIWrapper("CallNonvitual" XSTR(Result) "Method"); \ \ DTRACE_PROBE4(hotspot_jni, CallNonvirtual##Result##Method__entry, env, obj, cls, methodID);\ ------------ $arg3 points cls, $arg4 points methodID. In order to fix this problem, I made a patch for "hotspot_jni.stp.in" . The patch that attached this mail(hotspot_jni.patch) works well on RHEL6. ------------ [root at RHEL6 nonvirtual]# stap -c 'java -Djava.library.path=. Main' ../tapset/jnifunc.stp from JNI: env = 0x7fbbcc0071b8, obj = 0x7fbbd18e18c0, clazz = 0x7fbbcc068950, methodID = 0xcc064290 from CallStub! CallNonvirtualVoidMethod(env=0x7fbbcc0071b8,obj=0x7fbbd18e18c0,clazz=0x7fbbcc068950,methodid=0x7fbbcc064290), arg4=0x7fbbcc064290 ------------ Please merge this patch if you don't fix this problem yet. Best regards, Yasumasa -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tar.gz Type: application/x-gzip-compressed Size: 820 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110407/a63011ff/test.tar.gz -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hotspot_jni.patch Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110407/a63011ff/hotspot_jni.patch From mark at klomp.org Thu Apr 7 02:02:12 2011 From: mark at klomp.org (Mark Wielaard) Date: Thu, 07 Apr 2011 11:02:12 +0200 Subject: JNI functions "CallNonvirtual*" probe is incorrect In-Reply-To: <4D9D66B7.7060803@oss.ntt.co.jp> References: <4D9D66B7.7060803@oss.ntt.co.jp> Message-ID: <1302166932.9107.12.camel@springer.wildebeest.org> Hi Yasumasa, On Thu, 2011-04-07 at 16:24 +0900, Yasumasa Suenaga wrote: > Hi, > > I've tried to test my program with SystemTap. > When I probed CallNonvirtualVoidMethod(), I seem to get incorrect value through "hotspot_jni.stp". > [...] > "clazz" does not exist in hotspot_jni.stp, and methodid points clazz. > In HotSpot source code (hotspot/src/share/vm/prims/jni.cpp) defines CallNonvirtual functions as folllowing: > > ------------ > #define DEFINE_CALLNONVIRTUALMETHOD(ResultType, Result, Tag) \ > \ > DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##Method, ResultType);\ > DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##MethodV, ResultType);\ > DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##MethodA, ResultType);\ > \ > JNI_ENTRY(ResultType, \ > jni_CallNonvirtual##Result##Method(JNIEnv *env, jobject obj, jclass cls, jmethodID methodID, ...)) \ > JNIWrapper("CallNonvitual" XSTR(Result) "Method"); \ > \ > DTRACE_PROBE4(hotspot_jni, CallNonvirtual##Result##Method__entry, env, obj, cls, methodID);\ > ------------ > > $arg3 points cls, $arg4 points methodID. > > In order to fix this problem, I made a patch for "hotspot_jni.stp.in" . > The patch that attached this mail(hotspot_jni.patch) works well on RHEL6. Of course. CallNonVirtual methods take an extra jclass argument and somehow we missed this. Thanks so much for finding the issue and providing a patch. It looks good. I'll test it a bit and will commit it. Thanks, Mark From suenaga.yasumasa at oss.ntt.co.jp Thu Apr 7 02:26:20 2011 From: suenaga.yasumasa at oss.ntt.co.jp (Yasumasa Suenaga) Date: Thu, 07 Apr 2011 18:26:20 +0900 Subject: JNI functions "CallNonvirtual*" probe is incorrect In-Reply-To: <1302166932.9107.12.camel@springer.wildebeest.org> References: <4D9D66B7.7060803@oss.ntt.co.jp> <1302166932.9107.12.camel@springer.wildebeest.org> Message-ID: <4D9D833C.9050205@oss.ntt.co.jp> Hi Mark, Thank you for the reply. I wish that my patch pass your test :-) Thanks, Yasumasa (2011/04/07 18:02), Mark Wielaard wrote: > Hi Yasumasa, > > On Thu, 2011-04-07 at 16:24 +0900, Yasumasa Suenaga wrote: >> Hi, >> >> I've tried to test my program with SystemTap. >> When I probed CallNonvirtualVoidMethod(), I seem to get incorrect value through "hotspot_jni.stp". >> [...] >> "clazz" does not exist in hotspot_jni.stp, and methodid points clazz. >> In HotSpot source code (hotspot/src/share/vm/prims/jni.cpp) defines CallNonvirtual functions as folllowing: >> >> ------------ >> #define DEFINE_CALLNONVIRTUALMETHOD(ResultType, Result, Tag) \ >> \ >> DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##Method, ResultType);\ >> DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##MethodV, ResultType);\ >> DT_RETURN_MARK_DECL_FOR(Result, CallNonvirtual##Result##MethodA, ResultType);\ >> \ >> JNI_ENTRY(ResultType, \ >> jni_CallNonvirtual##Result##Method(JNIEnv *env, jobject obj, jclass cls, jmethodID methodID, ...)) \ >> JNIWrapper("CallNonvitual" XSTR(Result) "Method"); \ >> \ >> DTRACE_PROBE4(hotspot_jni, CallNonvirtual##Result##Method__entry, env, obj, cls, methodID);\ >> ------------ >> >> $arg3 points cls, $arg4 points methodID. >> >> In order to fix this problem, I made a patch for "hotspot_jni.stp.in" . >> The patch that attached this mail(hotspot_jni.patch) works well on RHEL6. > > Of course. CallNonVirtual methods take an extra jclass argument and > somehow we missed this. Thanks so much for finding the issue and > providing a patch. It looks good. I'll test it a bit and will commit it. > > Thanks, > > Mark > From adalbert.prokop at gmx.de Thu Apr 7 02:28:35 2011 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Thu, 07 Apr 2011 11:28:35 +0200 Subject: Question about IcedTea6 1.9.7 + Webstart (NetX) + OSGI In-Reply-To: <4D9C2716.4080603@redhat.com> References: <4D9C10E2.1040000@gmx.de> <4D9C2716.4080603@redhat.com> Message-ID: <4D9D83C3.60006@gmx.de> Am 06.04.2011 10:40, schrieb Andrew Haley: >> I've got a problem (and possibly a bug to report) with IcedTea6 1.9.7 >> using Webstart (NetX) and OSGI. >> Basically, calling BasicService.getCodeBase() always returns null if a >> webstart application uses OSGI. >> Is this worth a bug entry? > Yes. Please make sure the bug report contains a full test case. Gladly, but where do I report the bug? bugs.openjdk.java.net or bugreport.sun.com ? Sun's bug report's page is far too limited (no attachments) to create a test case, since multiple techniques are involved, which need multiple files (JNLP, Java and OSGI libs or at least references to them). -- best wishes Adalbert From mark at klomp.org Thu Apr 7 02:38:40 2011 From: mark at klomp.org (Mark Wielaard) Date: Thu, 07 Apr 2011 11:38:40 +0200 Subject: Question about IcedTea6 1.9.7 + Webstart (NetX) + OSGI In-Reply-To: <4D9D83C3.60006@gmx.de> References: <4D9C10E2.1040000@gmx.de> <4D9C2716.4080603@redhat.com> <4D9D83C3.60006@gmx.de> Message-ID: <1302169120.9107.13.camel@springer.wildebeest.org> On Thu, 2011-04-07 at 11:28 +0200, Adalbert Prokop wrote: > Am 06.04.2011 10:40, schrieb Andrew Haley: > > >> I've got a problem (and possibly a bug to report) with IcedTea6 1.9.7 > >> using Webstart (NetX) and OSGI. > >> Basically, calling BasicService.getCodeBase() always returns null if a > >> webstart application uses OSGI. > > >> Is this worth a bug entry? > > > Yes. Please make sure the bug report contains a full test case. > > Gladly, but where do I report the bug? bugs.openjdk.java.net or > bugreport.sun.com ? Sun's bug report's page is far too limited (no > attachments) to create a test case, since multiple techniques are > involved, which need multiple files (JNLP, Java and OSGI libs or at > least references to them). There is a real bugzilla at http://icedtea.classpath.org/bugzilla Cheers, Mark From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 03:04:07 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 10:04:07 +0000 Subject: [Bug 687] New: BasicService.getCodeBase() returns null for IcedTea6 1.9.7 + OSGI Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 Summary: BasicService.getCodeBase() returns null for IcedTea6 1.9.7 + OSGI Product: IcedTea-Web Version: unspecified Platform: all OS/Version: Windows Status: NEW Severity: normal Priority: P5 Component: NetX AssignedTo: omajid at redhat.com ReportedBy: adalbert.prokop at gmx.de CC: unassigned at icedtea.classpath.org Created an attachment (id=507) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=507) Eclipse plugin and feature source Calling BasicService.getCodeBase() always returns null if a webstart application uses OSGI. Sun/Oracle's (1.6.0_24) implementation behaves differently, they return the code base as defined in the JNLP file. I suspect the problem in the method JNLPSecurityManager. getApplication(Class[], int). The code iterates over all classes on the stack, retrieving their class loaders and checking their types. But in case of OSGI the method getClassLoader() will return null. System: Linux localhost 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:40:58 UTC 2011 i686 GNU/Linux Java version java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1) OpenJDK Client VM (build 19.0-b09, mixed mode, sharing) javaws version reports NetX 0.5 Steps to reproduce: To ways. 1. Unzip application from dummy.zip to /tmp 2. cd /tmp/features 3. run "javaws start.jnlp" With IcedTea6 1.9.7 you should see Hello World!! BasiceService.getCodeBase() returned: null or 1. Install both project in dummy_projects.tgz into eclipse 2. Run "File->Export" on dummy.feature 3. Select "Deployable features" 4. Tab "Destination": set directory to /tmp 5. Tab "Options": Select "Package as individual JARS archives" 6. Tab "JAR Signing": Use keystore from dummy plugin, alias: "dummy", passwords: "password" 7. Tab "Java Web Start": Check "Create JNLP manifest", set site URL to "file:/tmp" 8. Copy start.jnlp to /tmp/features 9. In /tmp/features run "javaws start.jnlp" Source code is contained in dummy_projects.tgz -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 03:29:14 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 10:29:14 +0000 Subject: [Bug 687] BasicService.getCodeBase() returns null for IcedTea6 1.9.7 + OSGI In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 --- Comment #1 from Adalbert Prokop 2011-04-07 10:29:14 --- The file dummy.zip can be downloaded from http://dl.dropbox.com/u/25570004/dummy.zip -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 10:16:25 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 17:16:25 +0000 Subject: [Bug 688] New: icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 Summary: icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself Product: IcedTea Version: 6-1.10.1 Platform: ppc OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Shark AssignedTo: unassigned at icedtea.classpath.org ReportedBy: acrux at linuxmail.org Created an attachment (id=508) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=508) hs_err_pid1856.log to build icedtea6-1.10.1 --enable-shark with llvm-2.9 i used: sed -i -e "s|llvm/System|llvm/Support|g" openjdk*/hotspot/src/share/vm/shark/llvmHeaders.hpp as llvm-2.9 moved its own headers from /include/llvm/System to /include/llvm/Support . I sucessfully built it: My configure: ./configure \ --with-openjdk-src-zip=$PKGMK_SOURCE_DIR/openjdk-6-src-b22-28_feb_2011.tar.gz \ --with-jaxp-drop-zip=$PKGMK_SOURCE_DIR/jaxp144_01.zip \ --with-jaf-drop-zip=$PKGMK_SOURCE_DIR/jdk6-jaf-b20.zip \ --with-jaxws-drop-zip=$PKGMK_SOURCE_DIR/jdk6-jaxws-b20.zip \ --with-pkgversion=cruxppc-2.7-${_arch} \ --with-jdk-home=${JDK_HOME} --disable-bootstrap \ --with-java=${JDK_HOME} \ --with-abs-install-dir=${JDK_HOME} \ --enable-zero --enable-shark \ --enable-nss \ --disable-docs \ --with-xalan2-jar=/usr/share/java/xalan2.jar \ --with-xerces2-jar=/usr/share/java/xercesImpl.jar \ --with-xalan2-serializer-jar=/usr/share/java/serializer.jar \ --with-rhino=/usr/share/java/js.jar \ --with-ant-home=/usr/lib/ant \ --with-parallel-jobs=2 # java -version java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.1) (cruxppc-2.7-ppc) OpenJDK Shark VM (build 19.0-b09, mixed mode) but when i try to re-build it again i get: [...] build-bootstrap-javac: [mkdir] Created dir: /mnt/DEVEL/next/icedtea6/0/work/src/icedtea6-1.10.1/openjdk.build/langtools/build/bootstrap/gensrc [mkdir] Created dir: /mnt/DEVEL/next/icedtea6/0/work/src/icedtea6-1.10.1/openjdk.build/langtools/build/bootstrap/classes [pcompile] Generating 7 resource files to /mnt/DEVEL/next/icedtea6/0/work/src/icedtea6-1.10.1/openjdk.build/langtools/build/bootstrap/gensrc [copy] Copying 1 file to /mnt/DEVEL/next/icedtea6/0/work/src/icedtea6-1.10.1/openjdk.build/langtools/build/bootstrap/gensrc [pcompile] Generating 1 resource files to /mnt/DEVEL/next/icedtea6/0/work/src/icedtea6-1.10.1/openjdk.build/langtools/build/bootstrap/gensrc [javac] Compiling 8 source files to /mnt/DEVEL/next/icedtea6/0/work/src/icedtea6-1.10.1/openjdk.build/langtools/build/bootstrap/classes [javac] Compiling 250 source files to /mnt/DEVEL/next/icedtea6/0/work/src/icedtea6-1.10.1/openjdk.build/langtools/build/bootstrap/classes [javac] # [javac] # A fatal error has been detected by the Java Runtime Environment: [javac] # [javac] # Internal Error (os_linux_zero.cpp:236), pid=1856, tid=1209738384 [javac] # fatal error: caught unhandled signal 4 [javac] # [javac] # JRE version: 6.0_22-b22 [javac] # Java VM: OpenJDK Shark VM (19.0-b09 mixed mode linux-ppc ) [javac] # Derivative: IcedTea6 1.10.1 [javac] # Distribution: Custom build (Thu Apr 7 15:40:28 CEST 2011) [javac] # An error report file with more information is saved as: [javac] # /mnt/DEVEL/next/icedtea6/0/work/src/icedtea6-1.10.1/openjdk/langtools/hs_err_pid1856.log [javac] # [javac] # If you would like to submit a bug report, please include [javac] # instructions how to reproduce the bug and visit: [javac] # http://icedtea.classpath.org/bugzilla [javac] # BUILD FAILED here attached hs_err_pid1856.log -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 10:20:29 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 17:20:29 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 acrux changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|icedtea6-1.10.1: OpenJDK |icedtea6-1.10.1: OpenJDK |Shark VM is unable to build |Shark VM is unable to build |itself |itself on ppc -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 10:34:43 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 17:34:43 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 Gary Benson changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #508|text/x-log |text/plain mime type| | -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 10:36:00 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 17:36:00 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 Gary Benson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gbenson at redhat.com --- Comment #1 from Gary Benson 2011-04-07 17:36:00 --- Signal 4 is illegal instruction: LLVM generated something nasty. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 13:17:44 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 20:17:44 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerxes at zafena.se --- Comment #2 from Xerxes R?nby 2011-04-07 20:17:44 --- Same story for every recent LLVM release. LLVM JIT inserts bl instructions to jump between generated code blocks, it crash when the distance between the blocks are out of range for a bl instruction. LLVM ppc and arm jit needs a workaround for this bug: icedtea PR399 llvm pr http://llvm.org/bugs/show_bug.cgi?id=5201 I assume that if you would have built llvm with assertions then you would have seen something like Assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out of range!"' failed -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 13:35:59 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 20:35:59 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 --- Comment #3 from Xerxes R?nby 2011-04-07 20:35:59 --- (In reply to comment #0) > to build icedtea6-1.10.1 --enable-shark with llvm-2.9 i used: > sed -i -e "s|llvm/System|llvm/Support|g" > openjdk*/hotspot/src/share/vm/shark/llvmHeaders.hpp > as llvm-2.9 moved its own headers from /include/llvm/System to > /include/llvm/Support . > btw.. nice catch! I have tested to build Shark against llvm 2.9 without hitting this.. possibly because i allready had old llvm headers in include/llvm/System. I have to verify this and patch the shark sources properly. Thank you for reporting this. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dbhole at redhat.com Thu Apr 7 14:51:41 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 7 Apr 2011 17:51:41 -0400 Subject: [icedtea-web] RFC: Make window close events use destroyApplet() Message-ID: <20110407215141.GA1184@redhat.com> Hi, Attached patch wires window close events to use destroyApplet() rather than appletClose(). destroyApplet() calls appletClose(), but is thread-safe and can be called multiple times safely unlike appletClose() which throws an NPE if called again (depending on timing). I think this patch should go into 1.0 as well. OK for both? ChangeLog: 2011-04-07 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (constructor): Make window close event call destroy applet which can be safely called multiple times, unlike appletClose. Cheers, Deepak -------------- next part -------------- diff -r 9c89214b7ef6 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Tue Apr 05 12:39:14 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 07 17:36:36 2011 -0400 @@ -407,7 +407,7 @@ windowEventListener = new WindowAdapter() { public void windowClosing(WindowEvent evt) { - appletClose(); + destroyApplet(identifier); } public void windowIconified(WindowEvent evt) { From dlila at redhat.com Thu Apr 7 14:58:59 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 7 Apr 2011 17:58:59 -0400 (EDT) Subject: [icedtea-web] RFC: Make window close events use destroyApplet() In-Reply-To: <20110407215141.GA1184@redhat.com> Message-ID: <1380165913.2095235.1302213539878.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > destroyApplet() calls appletClose(), but is thread-safe and can be > called > multiple times safely unlike appletClose() which throws an NPE if > called again (depending on timing). These NPE's have been pretty annoying. > I think this patch should go into 1.0 as well. OK for both? I'm ok with that. Regards, Denis. ----- Original Message ----- > Hi, > > Attached patch wires window close events to use destroyApplet() rather > than appletClose(). > > > > ChangeLog: > 2011-04-07 Deepak Bhole > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > (constructor): Make window close event call destroy applet which can > be > safely called multiple times, unlike appletClose. > > Cheers, > Deepak From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 15:03:16 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 22:03:16 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 --- Comment #4 from acrux @ cruxppc.org 2011-04-07 22:03:16 --- (In reply to comment #2) > Same story for every recent LLVM release. > > LLVM JIT inserts bl instructions to jump between generated code blocks, it > crash when the distance between the blocks are out of range for a bl > instruction. > > LLVM ppc and arm jit needs a workaround for this bug: > icedtea PR399 > llvm pr http://llvm.org/bugs/show_bug.cgi?id=5201 > > I assume that if you would have built llvm with assertions then you would have > seen something like > Assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out > of range!"' failed > mmh.. i built llvm with --disable-assertions, here you can read my build script: http://cruxppc.org/viewvc/opt/branches/2.7/llvm/Pkgfile?revision=2324&view=markup&pathrev=2324 Anyway is that old LLVM workaround still needed on PowerPC ? -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 7 15:05:35 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 07 Apr 2011 22:05:35 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 --- Comment #5 from acrux @ cruxppc.org 2011-04-07 22:05:35 --- (In reply to comment #3) > (In reply to comment #0) > > to build icedtea6-1.10.1 --enable-shark with llvm-2.9 i used: > > sed -i -e "s|llvm/System|llvm/Support|g" > > openjdk*/hotspot/src/share/vm/shark/llvmHeaders.hpp > > as llvm-2.9 moved its own headers from /include/llvm/System to > > /include/llvm/Support . > > > > btw.. nice catch! > > I have tested to build Shark against llvm 2.9 without hitting this.. possibly > because i allready had old llvm headers in include/llvm/System. > > I have to verify this and patch the shark sources properly. > > Thank you for reporting this. > you can see my ppc footprint's 2.8|2.9 diff here: http://cruxppc.org/viewvc/opt/branches/2.7/llvm/.footprint.powerpc?r1=2324&r2=2323&pathrev=2324 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dbhole at icedtea.classpath.org Thu Apr 7 15:07:34 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Thu, 07 Apr 2011 22:07:34 +0000 Subject: /hg/icedtea-web: Prevent NPE in appletClose() by calling it only... Message-ID: changeset 225421c775dd in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=225421c775dd author: Deepak Bhole date: Thu Apr 07 18:06:40 2011 -0400 Prevent NPE in appletClose() by calling it only via the thread-safe destroyApplet() method. diffstat: ChangeLog | 6 ++++++ plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diffs (25 lines): diff -r 24f034f372e4 -r 225421c775dd ChangeLog --- a/ChangeLog Wed Apr 06 10:02:46 2011 -0400 +++ b/ChangeLog Thu Apr 07 18:06:40 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-07 Deepak Bhole + + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java + (constructor): Make window close event call destroy applet which can be + safely called multiple times, unlike appletClose. + 2011-04-06 Andrew Su * netx/net/sourceforge/jnlp/controlpanel/AdvancedProxySettingsPane.java: diff -r 24f034f372e4 -r 225421c775dd plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 06 10:02:46 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 07 18:06:40 2011 -0400 @@ -407,7 +407,7 @@ windowEventListener = new WindowAdapter() { public void windowClosing(WindowEvent evt) { - appletClose(); + destroyApplet(identifier); } public void windowIconified(WindowEvent evt) { From dbhole at icedtea.classpath.org Thu Apr 7 15:07:44 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Thu, 07 Apr 2011 22:07:44 +0000 Subject: /hg/release/icedtea-web-1.0: Prevent NPE in appletClose() by cal... Message-ID: changeset 218e20b249b8 in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=218e20b249b8 author: Deepak Bhole date: Thu Apr 07 18:06:40 2011 -0400 Prevent NPE in appletClose() by calling it only via the thread-safe destroyApplet() method. diffstat: ChangeLog | 6 ++++++ plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diffs (25 lines): diff -r 9fd1cd238005 -r 218e20b249b8 ChangeLog --- a/ChangeLog Sun Apr 03 19:11:48 2011 -0400 +++ b/ChangeLog Thu Apr 07 18:06:40 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-07 Deepak Bhole + + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java + (constructor): Make window close event call destroy applet which can be + safely called multiple times, unlike appletClose. + 2011-04-04 Deepak Bhole * NEWS: Add 1.0.3 diff -r 9fd1cd238005 -r 218e20b249b8 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Sun Apr 03 19:11:48 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 07 18:06:40 2011 -0400 @@ -406,7 +406,7 @@ windowEventListener = new WindowAdapter() { public void windowClosing(WindowEvent evt) { - appletClose(); + destroyApplet(identifier); } public void windowIconified(WindowEvent evt) { From dbhole at redhat.com Thu Apr 7 15:08:39 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 7 Apr 2011 18:08:39 -0400 Subject: [icedtea-web] RFC: Make window close events use destroyApplet() In-Reply-To: <1380165913.2095235.1302213539878.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110407215141.GA1184@redhat.com> <1380165913.2095235.1302213539878.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110407220839.GB1184@redhat.com> * Denis Lila [2011-04-07 17:59]: > > destroyApplet() calls appletClose(), but is thread-safe and can be > > called > > multiple times safely unlike appletClose() which throws an NPE if > > called again (depending on timing). > > These NPE's have been pretty annoying. > Yeah I agree. They don't seem to have any ill effects but I hate them too. > > I think this patch should go into 1.0 as well. OK for both? > > I'm ok with that. > Okay, thanks for reviewing! Change pushed. Cheers, Deepak > Regards, > Denis. > > ----- Original Message ----- > > Hi, > > > > Attached patch wires window close events to use destroyApplet() rather > > than appletClose(). > > > > > > > > > > ChangeLog: > > 2011-04-07 Deepak Bhole > > > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > (constructor): Make window close event call destroy applet which can > > be > > safely called multiple times, unlike appletClose. > > > > Cheers, > > Deepak From ahughes at redhat.com Thu Apr 7 16:34:49 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 8 Apr 2011 00:34:49 +0100 Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <4D9B8310.8050201@redhat.com> References: <2072773307.397684.1302035233288.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <4D9B8310.8050201@redhat.com> Message-ID: <20110407233449.GA32676@rivendell.middle-earth.co.uk> On 17:01 Tue 05 Apr , Omair Majid wrote: > On 04/05/2011 04:27 PM, Andrew Su wrote: snip... > > + public void insertString(int offs, String str, AttributeSet a) throws BadLocationException { > > + if (str != null) { > > + try { > > + Integer.valueOf(str); What is this line doing? The return value is just thrown away. If that's deliberate, at least document it. > > + int val = Integer.valueOf(this.getText(0, this.getLength()) + str); > > + if (val< 1 || val> 65535) { // Invalid port number if true > > + throw new NumberFormatException("Invalid port number"); > > + } > > + super.insertString(offs, str, a); > > + } catch (Exception e) { > > + JOptionPane.showMessageDialog(null, Translator.R("CPInvalidPort"), Translator.R("CPInvalidPortTitle") > > + , JOptionPane.WARNING_MESSAGE); > > + } > > + } > > + return; > > + } > > + }; > > + } > > } > > diff -r eea730466b87 netx/net/sourceforge/jnlp/resources/Messages.properties > > --- a/netx/net/sourceforge/jnlp/resources/Messages.properties Tue Apr 05 14:38:22 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/resources/Messages.properties Tue Apr 05 16:26:59 2011 -0400 > > @@ -407,6 +407,8 @@ > > > > # Control Panel - Misc. > > CPJRESupport=IcedTea-Web currently does not support the use of multiple JREs. > > +CPInvalidPort=Invalid port number given.\n[Valid port numbers are 1-65535] > > +CPInvalidPortTitle=Error on input. > > > > # command line control panel > > CLNoInfo=No information avaiable (is this a valid option?). > > Everything else looks fine. > > Cheers, > Omair -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 7 16:49:51 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 8 Apr 2011 00:49:51 +0100 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser In-Reply-To: <4D9B28E3.4020600@redhat.com> References: <20110330220857.GH6143@rivendell.middle-earth.co.uk> <4D93C5ED.5000501@redhat.com> <20110331002116.GO6143@rivendell.middle-earth.co.uk> <4D94BC8E.5020301@redhat.com> <20110331182651.GE6143@rivendell.middle-earth.co.uk> <4D94D654.3020306@redhat.com> <20110331205614.GI6143@rivendell.middle-earth.co.uk> <4D964998.5010807@redhat.com> <20110405121241.GA2799@shelob.middle-earth.co.uk> <4D9B28E3.4020600@redhat.com> Message-ID: <20110407234951.GB32676@rivendell.middle-earth.co.uk> On 10:36 Tue 05 Apr , Omair Majid wrote: > On 04/05/2011 08:12 AM, Andrew John Hughes wrote: > > On Fri, Apr 01, 2011 at 05:54:32PM -0400, Omair Majid wrote: > >> On 03/31/2011 04:56 PM, Dr Andrew John Hughes wrote: > >>> On 15:30 Thu 31 Mar , Omair Majid wrote: > >>>> On 03/31/2011 02:26 PM, Dr Andrew John Hughes wrote: > >>>>> On 13:40 Thu 31 Mar , Omair Majid wrote: > >>>>>> On 03/30/2011 08:21 PM, Dr Andrew John Hughes wrote: > >>>>>>> > >>>>>>> It does need documenting in README, but I'm happy for that to be a separate patch. > >>>>>> > >>>>>> Patch attached. Does that look okay? > >>>>>> > >>>>> > >>>>> It's a bit brief. > >>>>> > >>>>> * What about documenting the --with-rhino/junit options? > >>>>> * What about something specific about the JUnit tests? > >>>> > >>>> Okay, how about the new patch? > >>>> > >>> Still nothing on the JUnit stuff, which was the main reason I thought we were > >>> patching the docs. The custom output and the reasoning for it should be noted > >>> IMHO. > >>> > >> > >> Ah, _now_ I get it. I thought by JUnit, you were referring to JUnit > >> itself, not our frontend/formatter for it. > >> > > > > Sorry, should have been clearer. > > > > No worries. > > >> I thought my documentation of that in tests/junit-runner/README was > >> sufficient. Anyway, I have updated the README for that too. Any > >> other suggestions? > > > > Ok, I'd forgotten about that file. The changes aren't in the patch below, though... > > > > This bit below is what I was referring to: > > >> +A custom JUnit ouput formatter is supplied. This makes the output of JUnit > >> +tests match the output of other tests. A simple 'Passed:' or 'FAILED:' is > >> +printed out, followed by.. This is also the format used > >> +by JTreg. > Ok, looks good. Please commit. > Cheers, > Omair -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 7 16:54:27 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 8 Apr 2011 00:54:27 +0100 Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <2103760228.367192.1301933551551.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1909360645.366465.1301932420619.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <2103760228.367192.1301933551551.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110407235427.GC32676@rivendell.middle-earth.co.uk> On 12:12 Mon 04 Apr , Andrew Su wrote: > Hi, > > I have attached a patch for changing how cache stores its entries to fix some problems that existed in the current cache system. > > Right now the jar files may be overwritten by another plugin/javaws when a new version is pushed while the user is using an old version (prior update) then open another instance of the applet/javaws. With the patch this gets fixed by creating a new location for the update to be downloaded to instead of overwriting the current file. > > [I'm going to use applet, but assume I mean applet+javaws] > Another issue with the current one is.. When loading the same applet twice (or more), it could detect that it's not current and both applet would download to the same place. In the patch, we will wait for the download to finish first then check if we have already downloaded it. If so just proceed without re-downloading. > > This patch makes the cache keep track of the most recently used items and remove items until we hit the cache limit if set. > > Changelog: > > 2011-04-04 Andrew Su > > * netx/net/sourceforge/jnlp/cache/CacheEntry.java: > (markForDelete, lock, unlock): New methods. > * netx/net/sourceforge/jnlp/cache/CacheUtil.java: > (getCacheFile): Changed to look for most recently used item, and when > not found create a new entry. > (makeNewCacheFile, cleanCache, lockFile, unlockFile, > lockRecentlyUsedFile, unlockRecentlyUsedFile): New methods. > * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > (downloadResource): Changed to wait if we are already downloading the > file. If file downloaded is compressed, mark compressed and extracted > files for delete at shutdown. > (initializeResource): Added checks for when the cache needs updating > to create new folder entry. > * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: > (JNLPClassLoader): Change order so that we get resources first then > check permissions for the jars. > * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: > (markNetxRunning): Add call to clean up cache directory. > * netx/net/sourceforge/jnlp/util/FileUtils.java: > (getFileLock): New method. > > Any questions or comments welcome. > > Cheers, > Andrew I haven't looked over the whole patch, but I was disturbed by the use of 'RecentlyUsed' as the filename. Do we have other instances of mixed case in NetX? I would have thought something like 'recently_used' would be more appropriate. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 7 17:28:26 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 8 Apr 2011 01:28:26 +0100 Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <1086482658.1960260.1302020000656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1220523441.1960231.1302019863798.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <1086482658.1960260.1302020000656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110408002826.GE32676@rivendell.middle-earth.co.uk> On 12:13 Tue 05 Apr , Denis Lila wrote: > Hi. > > I think I found a concurrency problem in > ResourceTracker.addResource. This method is not static. > It is called from different threads, and it writes to > downloadOptions which is a static HashMap. This is not > safe. The patch uses a ConcurrentHashMap. That should > be enough to fix it. > > Ok to push? > > Regards, > Denis. No, this isn't enough. This piece of code: private URL findBestUrl(Resource resource) { 1. DownloadOptions options = downloadOptions.get(resource); 2. if (options == null) { 3. options = new DownloadOptions(false, false); } may be subject to a race from addResource. Line 1 may retrieve null, but that thread may then be interrupted before line 2 can be executed. In the meantime, the resource could be added to downloadOptions and this thread would still have the old stale value. It's also odd code in that this new instance is created but not stored in the map. So it seems possible that many threads could call this method, all get a return value of null and create new instances of DownloadOptions. The control flow in this class is not very clear, but I presume the null check means that there is a possibility that this method can be called before the resource is added in addResource. I would suggest replacing those three lines with: DownloadOptions options = downloadOptions.putIfAbsent(resource, new DownloadOptions(false,false)); This ensures, atomically, that any existing value is retrieved and stored in options, but if one is not present, the default is added and returned. With addResource using put instead of putIfAbsent, it should still override a default added by this method. This also means there's a reason to follow Andrew's suggestion, as putIfAbsent is unique to ConcurrentHashMap. In general, the interface type (Map) should be used rather than the specific type to allow easy transition between different implementations. It prevents code using implementation-specific methods which would make later implementation changes harder e.g. if this class had been using HashMap directly, it may have relied on HashMap-only methods. > diff -r 62011060e7ea ChangeLog > --- a/ChangeLog Tue Apr 05 12:07:10 2011 -0400 > +++ b/ChangeLog Tue Apr 05 12:12:33 2011 -0400 > @@ -1,3 +1,9 @@ > +2011-04-05 Denis Lila > + > + * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > + Remove unused import, add import. > + (downloadOptions): Make ConcurrentHashMap. > + > 2011-04-05 Denis Lila > > * plugin/icedteanp/IcedTeaNPPlugin.cc > diff -r 62011060e7ea netx/net/sourceforge/jnlp/cache/ResourceTracker.java > --- a/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Tue Apr 05 12:07:10 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/ResourceTracker.java Tue Apr 05 12:12:33 2011 -0400 > @@ -29,9 +29,9 @@ > import java.net.URL; > import java.net.URLConnection; > import java.util.ArrayList; > -import java.util.HashMap; > import java.util.List; > import java.util.Map; > +import java.util.concurrent.ConcurrentHashMap; > import java.util.jar.JarOutputStream; > import java.util.jar.Pack200; > import java.util.jar.Pack200.Unpacker; > @@ -121,7 +121,7 @@ > private static ArrayList queue = new ArrayList(); > > private static Map downloadOptions = > - new HashMap(); > + new ConcurrentHashMap(); > > /** resource trackers threads are working for (used for load balancing across multi-tracker downloads) */ > private static ArrayList active = -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 7 17:33:04 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 8 Apr 2011 01:33:04 +0100 Subject: [RFC][plugin]: part 2 of changeset 191 In-Reply-To: <351086047.1961391.1302024154819.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <991423935.1961368.1302024035415.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <351086047.1961391.1302024154819.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110408003304.GF32676@rivendell.middle-earth.co.uk> On 13:22 Tue 05 Apr , Denis Lila wrote: > Hi. > > In changeset 191 I replaced PluginDebug.debug(String) > by PluginDebug.debug(Object...). I also changed all > uses of that method to use the varargs. However, it > seems I forgot to change the uses in the netscape.javascript > package. The attached patch does that. > You should identify changes by the changeset id, as the revision ID is not guaranteed to be applicable across multiple checkouts. The change otherwise looks fine, but I think it's worth considering a separate patch for this code which cleans up some of this output particularly the 'GOT' and 'GOT IT' messages. 'retrieved' would be better in both cases. > Ok to push? > > Thank you, > Denis. > diff -r 9c89214b7ef6 ChangeLog > --- a/ChangeLog Tue Apr 05 12:39:14 2011 -0400 > +++ b/ChangeLog Tue Apr 05 13:21:02 2011 -0400 > @@ -1,3 +1,9 @@ > +2011-04-05 Denis Lila > + > + * plugin/icedteanp/java/netscape/javascript/JSObject.java: > + Replaced every instance of PluginDebug.debug(a + b + c...) > + with PluginDebug.debug(a, b, c...). > + > 2011-04-05 Denis Lila > > * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > diff -r 9c89214b7ef6 plugin/icedteanp/java/netscape/javascript/JSObject.java > --- a/plugin/icedteanp/java/netscape/javascript/JSObject.java Tue Apr 05 12:39:14 2011 -0400 > +++ b/plugin/icedteanp/java/netscape/javascript/JSObject.java Tue Apr 05 13:21:02 2011 -0400 > @@ -150,10 +150,10 @@ > * Equivalent to "this.name" in JavaScript. > */ > public Object getMember(String name) { > - PluginDebug.debug("JSObject.getMember " + name); > + PluginDebug.debug("JSObject.getMember ", name); > > Object o = PluginAppletViewer.getMember(internal, name); > - PluginDebug.debug("JSObject.getMember GOT " + o); > + PluginDebug.debug("JSObject.getMember GOT ", o); > return o; > } > > @@ -163,7 +163,7 @@ > */ > // public Object getMember(int index) { return getSlot(index); } > public Object getSlot(int index) { > - PluginDebug.debug("JSObject.getSlot " + index); > + PluginDebug.debug("JSObject.getSlot ", index); > > return PluginAppletViewer.getSlot(internal, index); > } > @@ -173,7 +173,7 @@ > * Equivalent to "this.name = value" in JavaScript. > */ > public void setMember(String name, Object value) { > - PluginDebug.debug("JSObject.setMember " + name + " " + value); > + PluginDebug.debug("JSObject.setMember ", name, " ", value); > > PluginAppletViewer.setMember(internal, name, value); > } > @@ -186,7 +186,7 @@ > // setSlot(index, value); > // } > public void setSlot(int index, Object value) { > - PluginDebug.debug("JSObject.setSlot " + index + " " + value); > + PluginDebug.debug("JSObject.setSlot ", index, " ", value); > > PluginAppletViewer.setSlot(internal, index, value); > } > @@ -195,7 +195,7 @@ > * Removes a named member of a JavaScript object. > */ > public void removeMember(String name) { > - PluginDebug.debug("JSObject.removeMember " + name); > + PluginDebug.debug("JSObject.removeMember ", name); > > PluginAppletViewer.removeMember(internal, name); > } > @@ -208,9 +208,9 @@ > if (args == null) > args = new Object[0]; > > - PluginDebug.debug("JSObject.call " + methodName); > + PluginDebug.debug("JSObject.call ", methodName); > for (int i = 0; i < args.length; i++) > - PluginDebug.debug(" " + args[i]); > + PluginDebug.debug(" ", args[i]); > PluginDebug.debug(""); > return PluginAppletViewer.call(internal, methodName, args); > } > @@ -221,7 +221,7 @@ > * given by "this". > */ > public Object eval(String s) { > - PluginDebug.debug("JSObject.eval " + s); > + PluginDebug.debug("JSObject.eval ", s); > return PluginAppletViewer.eval(internal, s); > } > > @@ -246,7 +246,7 @@ > long internal = 0; > internal = ((PluginAppletViewer) > applet.getAppletContext()).getWindow(); > - PluginDebug.debug("GOT IT: " + internal); > + PluginDebug.debug("GOT IT: ", internal); > return new JSObject(internal); > } > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 7 17:40:57 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 8 Apr 2011 01:40:57 +0100 Subject: Question about IcedTea6 1.9.7 + Webstart (NetX) + OSGI In-Reply-To: <1302169120.9107.13.camel@springer.wildebeest.org> References: <4D9C10E2.1040000@gmx.de> <4D9C2716.4080603@redhat.com> <4D9D83C3.60006@gmx.de> <1302169120.9107.13.camel@springer.wildebeest.org> Message-ID: <20110408004057.GH32676@rivendell.middle-earth.co.uk> On 11:38 Thu 07 Apr , Mark Wielaard wrote: > On Thu, 2011-04-07 at 11:28 +0200, Adalbert Prokop wrote: > > Am 06.04.2011 10:40, schrieb Andrew Haley: > > > > >> I've got a problem (and possibly a bug to report) with IcedTea6 1.9.7 > > >> using Webstart (NetX) and OSGI. > > >> Basically, calling BasicService.getCodeBase() always returns null if a > > >> webstart application uses OSGI. > > > > >> Is this worth a bug entry? > > > > > Yes. Please make sure the bug report contains a full test case. > > > > Gladly, but where do I report the bug? bugs.openjdk.java.net or > > bugreport.sun.com ? Sun's bug report's page is far too limited (no > > attachments) to create a test case, since multiple techniques are > > involved, which need multiple files (JNLP, Java and OSGI libs or at > > least references to them). > > There is a real bugzilla at http://icedtea.classpath.org/bugzilla > Yes, the one Mark mentions. The IcedTea JNLP support is a completely independent implementation. Sun/Oracle never released their code as FOSS. > Cheers, > > Mark > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 7 17:43:12 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 8 Apr 2011 01:43:12 +0100 Subject: Various backports for IcedTea6-1.8, IcedTea6-1.9 and IcedTea6-1.10 In-Reply-To: <4D9C1D37.6020800@redhat.com> References: <4D9C1D37.6020800@redhat.com> Message-ID: <20110408004312.GI32676@rivendell.middle-earth.co.uk> On 09:58 Wed 06 Apr , Pavel Tisnovsky wrote: > Hi Andrew, > > could you please review backports I made for IcedTea6-1.8 and IcedTea6-1.9: > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/013316.html > > I'd also like to have this backports for IcedTea6-1.10 reviewed, could > you please do that?: > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013377.html > The links are pretty useless as the OpenJDK mailing list archives don't seem to retain attachments. I'll try and find them in my inbox but may be quicker to simply repost with a 'PING' prefix on the subject. > Thank you VM in advance > Pavel -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From adalbert.prokop at gmx.de Thu Apr 7 23:41:50 2011 From: adalbert.prokop at gmx.de (Adalbert Prokop) Date: Fri, 08 Apr 2011 08:41:50 +0200 Subject: Question about IcedTea6 1.9.7 + Webstart (NetX) + OSGI In-Reply-To: <20110408004057.GH32676@rivendell.middle-earth.co.uk> References: <4D9C10E2.1040000@gmx.de> <4D9C2716.4080603@redhat.com> <4D9D83C3.60006@gmx.de> <1302169120.9107.13.camel@springer.wildebeest.org> <20110408004057.GH32676@rivendell.middle-earth.co.uk> Message-ID: <4D9EAE2E.10500@gmx.de> On 08.04.2011 02:40, Dr Andrew John Hughes wrote: > On 11:38 Thu 07 Apr , Mark Wielaard wrote: >> On Thu, 2011-04-07 at 11:28 +0200, Adalbert Prokop wrote: >> There is a real bugzilla at http://icedtea.classpath.org/bugzilla > Yes, the one Mark mentions. The IcedTea JNLP support is a completely > independent implementation. Sun/Oracle never released their code > as FOSS. Yes, thank you for pointing out. I was searching for "Bugzilla" and "OpenJDK", which led me to http://bugs.openjdk.java.net. Once there you can find a pointer to Sun/Oracle's bug report service - the confusion was complete. It's a challenge of its own to find the right site for the various components. -- best wishes Adalbert From bugzilla-daemon at icedtea.classpath.org Fri Apr 8 00:54:29 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 08 Apr 2011 07:54:29 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 --- Comment #6 from Xerxes R?nby 2011-04-08 07:54:28 --- (In reply to comment #4) > (In reply to comment #2) > > Same story for every recent LLVM release. > > > > LLVM JIT inserts bl instructions to jump between generated code blocks, it > > crash when the distance between the blocks are out of range for a bl > > instruction. > > > > LLVM ppc and arm jit needs a workaround for this bug: > > icedtea PR399 > > llvm pr http://llvm.org/bugs/show_bug.cgi?id=5201 > > > > I assume that if you would have built llvm with assertions then you would have > > seen something like > > Assertion `ResultPtr >= -(1 << 23) && ResultPtr < (1 << 23) && "Relocation out > > of range!"' failed > > > > mmh.. i built llvm with --disable-assertions, here you can read my build > script: > http://cruxppc.org/viewvc/opt/branches/2.7/llvm/Pkgfile?revision=2324&view=markup&pathrev=2324 > > Anyway is that old LLVM workaround still needed on PowerPC ? If the old LLVM workaround = building for ppc32 then YES, this are still needed: 20 CONF="--with-cxx-include-32bit-dir=32" Building LLVM for ppc64 are still unsupported by the 2.9 release. see: http://llvm.org/bugs/show_bug.cgi?id=9529 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Fri Apr 8 03:53:31 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 08 Apr 2011 10:53:31 +0000 Subject: [Bug 689] New: Shark failes to find LLVM 2.9 System headers during build. Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=689 Summary: Shark failes to find LLVM 2.9 System headers during build. Product: IcedTea Version: 6-hg Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Shark AssignedTo: unassigned at icedtea.classpath.org ReportedBy: xerxes at zafena.se LLVM 2.9 are out, cool! Testcase build Shark against llvm 2.9: wget http://llvm.org/releases/2.9/llvm-2.9.tgz tar zxvf llvm-2.9.tgz mkdir llvm-2.9-build cd llvm-2.9-build ../llvm-2.9/configure --enable-targets=arm,powerpc,x86 --enable-shared --enable-assertions -enable-optimized --enable-docs=no --enable-debug-symbols=yes make sudo make install sudo ldconfig cd .. hg clone http://icedtea.classpath.org/hg/icedtea6 cd icedtea6 ./autogen.sh cd .. mkdir icedtea6-shark cd icedtea6-shark ../icedtea6/configure --enable-shark make Fails with: In file included from ../generated/incls/_compileBroker.cpp.incl:8, from /home/xerxes/icedtea6-1.10.1-shark/openjdk-ecj/hotspot/src/share/vm/compiler/compileBroker.cpp:26: /home/xerxes/icedtea6-1.10.1-shark/openjdk-ecj/hotspot/src/share/vm/shark/llvmHeaders.hpp:46: fatal error: llvm/System/Threading.h: No such file or directory compilation terminated. Why? llvm/System/Threading.h and llvm/System/Host.h have been moved to llvm/Support/Threading.h and llvm/Support/Host.h Attached patches fix this for icedtea6-1.9 icedtea6-1.10 and icedtea6 trunk: -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Fri Apr 8 03:59:25 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 08 Apr 2011 10:59:25 +0000 Subject: [Bug 689] Shark failes to find LLVM 2.9 System headers during build. In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=689 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|unassigned at icedtea.classpath|xerxes at zafena.se |.org | Status|NEW |ASSIGNED --- Comment #1 from Xerxes R?nby 2011-04-08 10:59:25 --- Created an attachment (id=510) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=510) icedtea6-1.9-shark-llvm-2.9.patch patch for icedtea6-1.9 release branch. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Fri Apr 8 04:15:25 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 08 Apr 2011 11:15:25 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 --- Comment #7 from Xerxes R?nby 2011-04-08 11:15:24 --- (In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #0) > > > to build icedtea6-1.10.1 --enable-shark with llvm-2.9 i used: > > > sed -i -e "s|llvm/System|llvm/Support|g" > > > openjdk*/hotspot/src/share/vm/shark/llvmHeaders.hpp > > > as llvm-2.9 moved its own headers from /include/llvm/System to > > > /include/llvm/Support . > > > > > > > btw.. nice catch! > > > > I have tested to build Shark against llvm 2.9 without hitting this.. possibly > > because i allready had old llvm headers in include/llvm/System. > > > > I have to verify this and patch the shark sources properly. > > > > Thank you for reporting this. > > > > you can see my ppc footprint's 2.8|2.9 diff here: > http://cruxppc.org/viewvc/opt/branches/2.7/llvm/.footprint.powerpc?r1=2324&r2=2323&pathrev=2324 > Thanks, I have created a new bug 689 for this generic Shark + LLVM 2.9 header issue. http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=689 Cheers Xerxes -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Fri Apr 8 05:09:21 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 08 Apr 2011 12:09:21 +0000 Subject: [Bug 690] New: Shark fails to JIT using hs20. Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=690 Summary: Shark fails to JIT using hs20. Product: IcedTea Version: 6-hg Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Shark AssignedTo: unassigned at icedtea.classpath.org ReportedBy: xerxes at zafena.se #Shark built against hs20 fails to JIT. icedtea6-shark/openjdk.build/j2sdk-image/bin/java -version java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.11pre+r0239a181c7a0+) (Ubuntu build 1.6.0_22-b22) OpenJDK Shark VM (build 20.0-b11, mixed mode) xerxes at xerxes-J464X:~/cm30$ ../icedtea6-shark/openjdk.build/j2sdk-image/bin/java CaffeineMarkEmbeddedApp Sieve score = 2648 (98) Loop score = 1746 (2017) Logic score = 2459 (0) String score = 4048 (708) Float score = 1836 (185) Method score = 1490 (166650) Overall score = 2238 #When running Shark built against hs19 then the JIT works fine. icedtea6-1.10.1-shark/openjdk.build/j2sdk-image/bin/java -version java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.10.1) (Ubuntu build 1.6.0_22-b22) OpenJDK Shark VM (build 19.0-b09, mixed mode) xerxes at xerxes-J464X:~/cm30$ ../icedtea6-1.10.1-shark/openjdk.build/j2sdk-image/bin/java CaffeineMarkEmbeddedApp Sieve score = 39428 (98) Loop score = 53694 (2017) Logic score = 70981 (0) String score = 26422 (708) Float score = 34138 (185) Method score = 20375 (166650) Overall score = 37456 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From john.connett at ntlworld.com Fri Apr 8 05:19:41 2011 From: john.connett at ntlworld.com (John Connett) Date: Fri, 08 Apr 2011 13:19:41 +0100 Subject: OpenWrt/backfire + IcedTea + mips? Message-ID: <1302265181.4950.23.camel@master.home> Anyone tried this combination? Any comments? On my potential target: # cat /proc/cpuinfo system type : Atheros AR9132 rev 2 machine : Buffalo WZR-HP-G300NH processor : 0 cpu model : MIPS 24Kc V7.4 BogoMIPS : 266.24 wait instruction : yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 4, address/irw mask: [0x0000, 0x0000, 0x0020, 0x0048] ASEs implemented : mips16 shadow register sets : 1 core : 0 VCED exceptions : not available VCEI exceptions : not available From asu at redhat.com Fri Apr 8 06:17:51 2011 From: asu at redhat.com (Andrew Su) Date: Fri, 8 Apr 2011 09:17:51 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <212459532.2020829.1302108632117.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1012691594.456901.1302268671917.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > Hi again. > > My previous e-mail was mostly just low level implementation > comments. I have only one problem with the design: > right now our cache management metadata is stored in RecentlyUsed > which is a map. Storing > information about the time of last update of a cached > resource using the time as a key seems very unnatural to me. > > Right now, CacheLRUPolicy.cacheOrder isn't really a hash map > at all. It's just a list of couples because > every time we read from it we start out with the name and try > to read the time. In other words, given the value we try to > read the key. That is very backwards for a hash map, which > is supposed to provide the value given the key. > > If we could somehow make the resource that we're caching the > key and the time of last update the value, I think that would > simplify things a lot. In particular we might be able to > entirely get rid of these identifiers that we're adding to > folder names and times. And also checking whether something > is in the cache and updating it should be made much simpler > (no loops would be required). > > What do you think? Hi Denis, At first it sounded like a good idea to me. However, after closer inspection it comes with the issue that when let's say you try check for something on www.example.com/example.jar, using that we can use it to check that it's a key, but when it comes time to update (download a new copy) it'd need to store it in a separate location (which in the end we will be looping over the keys). Overwriting any of the jar files is bad since we don't know if they are in use. I hope that made sense.. --snip-- Cheers, Andrew From asu at redhat.com Fri Apr 8 06:19:17 2011 From: asu at redhat.com (Andrew Su) Date: Fri, 8 Apr 2011 09:19:17 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <20110407235427.GC32676@rivendell.middle-earth.co.uk> Message-ID: <2006587670.456948.1302268757500.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 12:12 Mon 04 Apr , Andrew Su wrote: > > Hi, > > > > I have attached a patch for changing how cache stores its entries > > to fix some problems that existed in the current cache system. > > > > Right now the jar files may be overwritten by another plugin/javaws > > when a new version is pushed while the user is using an old version > > (prior update) then open another instance of the applet/javaws. With > > the patch this gets fixed by creating a new location for the update > > to be downloaded to instead of overwriting the current file. > > > > [I'm going to use applet, but assume I mean applet+javaws] > > Another issue with the current one is.. When loading the same applet > > twice (or more), it could detect that it's not current and both > > applet would download to the same place. In the patch, we will wait > > for the download to finish first then check if we have already > > downloaded it. If so just proceed without re-downloading. > > > > This patch makes the cache keep track of the most recently used > > items and remove items until we hit the cache limit if set. > > > > Changelog: > > > > 2011-04-04 Andrew Su > > > > * netx/net/sourceforge/jnlp/cache/CacheEntry.java: > > (markForDelete, lock, unlock): New methods. > > * netx/net/sourceforge/jnlp/cache/CacheUtil.java: > > (getCacheFile): Changed to look for most recently used item, > > and when > > not found create a new entry. > > (makeNewCacheFile, cleanCache, lockFile, unlockFile, > > lockRecentlyUsedFile, unlockRecentlyUsedFile): New methods. > > * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: > > (downloadResource): Changed to wait if we are already > > downloading the > > file. If file downloaded is compressed, mark compressed and > > extracted > > files for delete at shutdown. > > (initializeResource): Added checks for when the cache needs > > updating > > to create new folder entry. > > * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: > > (JNLPClassLoader): Change order so that we get resources > > first then > > check permissions for the jars. > > * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: > > (markNetxRunning): Add call to clean up cache directory. > > * netx/net/sourceforge/jnlp/util/FileUtils.java: > > (getFileLock): New method. > > > > Any questions or comments welcome. > > > > Cheers, > > Andrew > > I haven't looked over the whole patch, but I was disturbed by the use > of 'RecentlyUsed' > as the filename. Do we have other instances of mixed case in NetX? I > would have > thought something like 'recently_used' would be more appropriate. Not a problem to change. Cheers, Andrew From omajid at redhat.com Fri Apr 8 07:04:03 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 08 Apr 2011 10:04:03 -0400 Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <20110407233449.GA32676@rivendell.middle-earth.co.uk> References: <2072773307.397684.1302035233288.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <4D9B8310.8050201@redhat.com> <20110407233449.GA32676@rivendell.middle-earth.co.uk> Message-ID: <4D9F15D3.6080300@redhat.com> On 04/07/2011 07:34 PM, Dr Andrew John Hughes wrote: > On 17:01 Tue 05 Apr , Omair Majid wrote: >> On 04/05/2011 04:27 PM, Andrew Su wrote: > > snip... > >>> + public void insertString(int offs, String str, AttributeSet a) throws BadLocationException { >>> + if (str != null) { >>> + try { >>> + Integer.valueOf(str); > > What is this line doing? The return value is just thrown away. > If that's deliberate, at least document it. > Integer.valueOf throws an Exception (NumberFormatException to be precise) if the input can not be parsed as a number. That said, since we are already doing Integer.valueOf (on oldString + str) on the next line, perhaps this line can be removed completely? Cheers, Omair From asu at redhat.com Fri Apr 8 07:08:16 2011 From: asu at redhat.com (Andrew Su) Date: Fri, 8 Apr 2011 10:08:16 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <4D9F15D3.6080300@redhat.com> Message-ID: <1686768841.458314.1302271696623.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > On 04/07/2011 07:34 PM, Dr Andrew John Hughes wrote: > > On 17:01 Tue 05 Apr , Omair Majid wrote: > >> On 04/05/2011 04:27 PM, Andrew Su wrote: > > > > snip... > > > >>> + public void insertString(int offs, String str, AttributeSet a) > >>> throws BadLocationException { > >>> + if (str != null) { > >>> + try { > >>> + Integer.valueOf(str); > > > > What is this line doing? The return value is just thrown away. > > If that's deliberate, at least document it. > > > > Integer.valueOf throws an Exception (NumberFormatException to be > precise) if the input can not be parsed as a number. That said, since > we > are already doing Integer.valueOf (on oldString + str) on the next > line, > perhaps this line can be removed completely? Yes, you are right we can remove that line completely. Cheers, Andrew From asu at redhat.com Fri Apr 8 07:12:07 2011 From: asu at redhat.com (Andrew Su) Date: Fri, 8 Apr 2011 10:12:07 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <1686768841.458314.1302271696623.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <110314578.458395.1302271927054.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Bah, here's the patch. Sorry for the noise. ----- Original Message ----- > ----- Original Message ----- > > On 04/07/2011 07:34 PM, Dr Andrew John Hughes wrote: > > > On 17:01 Tue 05 Apr , Omair Majid wrote: > > >> On 04/05/2011 04:27 PM, Andrew Su wrote: > > > > > > snip... > > > > > >>> + public void insertString(int offs, String str, AttributeSet a) > > >>> throws BadLocationException { > > >>> + if (str != null) { > > >>> + try { > > >>> + Integer.valueOf(str); > > > > > > What is this line doing? The return value is just thrown away. > > > If that's deliberate, at least document it. > > > > > > > Integer.valueOf throws an Exception (NumberFormatException to be > > precise) if the input can not be parsed as a number. That said, > > since > > we > > are already doing Integer.valueOf (on oldString + str) on the next > > line, > > perhaps this line can be removed completely? > > Yes, you are right we can remove that line completely. > > Cheers, > Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110408_remove_redundant_line.patch Type: text/x-patch Size: 789 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110408/2bfea68d/20110408_remove_redundant_line.patch From omajid at icedtea.classpath.org Fri Apr 8 07:19:34 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Fri, 08 Apr 2011 14:19:34 +0000 Subject: /hg/icedtea-web: Update README with information about junit test... Message-ID: changeset e7c791aa1bd2 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=e7c791aa1bd2 author: Omair Majid date: Fri Apr 08 10:17:36 2011 -0400 Update README with information about junit tests and rhino diffstat: ChangeLog | 4 ++++ README | 45 +++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+), 0 deletions(-) diffs (77 lines): diff -r 225421c775dd -r e7c791aa1bd2 ChangeLog --- a/ChangeLog Thu Apr 07 18:06:40 2011 -0400 +++ b/ChangeLog Fri Apr 08 10:17:36 2011 -0400 @@ -1,3 +1,7 @@ +2011-04-08 Omair Majid + + * README: Update to add notes on rhino and junit. + 2011-04-07 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java diff -r 225421c775dd -r e7c791aa1bd2 README --- a/README Thu Apr 07 18:06:40 2011 -0400 +++ b/README Fri Apr 08 10:17:36 2011 -0400 @@ -66,6 +66,11 @@ The plugin can be disabled by passing --disable-plugin. +The following optional dependencies enable additional features + +* rhino (enables support for using proxy auto config files) +* junit4 (enables unit tests) + See ./configure --help if you need to override the defaults. The following locations are checked for a JDK: @@ -113,10 +118,50 @@ These are documented fully in the relevant section below. * --disable-plugin: Don't build the browser plugin. +* --with-rhino: Specify the location of rhino jar +* --with-junit: Specify the location of the junit 4 jar + +Rhino Support +============= + +IcedTea-Web needs rhino for using Proxy Auto Config (PAC) files. If rhino is +not found, or explicitly disabled, then support for PAC files will be disabled. + +By default, the following paths are checked for rhino: + - /usr/share/java/js.jar + - /usr/share/rhino-1.6/lib/js.jar + - /usr/share/java/rhino.jar + +If a rhino jar is not found, rhino support is disabled. The --with-rhino build +option can be used to specify the location of the jar file. To explicitly +disable rhino use --with-rhino=no. + +JUnit Support +============= + +JUnit is needed for running some tests. It has no run-time impact. + +By default, the following paths are checked: + - /usr/share/java/junit4.jar + +If JUnit is not found, JUnit support is disabled. The --with-junit option can +be used to specify the location of the JUnit 4 jar. To disable JUnit support +explicitly, use --with-junit=no. + +A custom JUnit ouput formatter is supplied. This makes the output of JUnit +tests match the output of other tests. A simple 'Passed:' or 'FAILED:' is +printed out, followed by .. This is also the format used +by JTreg. Testing ======= +A set of automated tests is supplied for IcedTea-Web. They can be run by using +'make check'. Currently, this only tests a few parts of IcedTea-Web. + +The number and type of tests run by 'make check' may be affected by the build +options, including JUnit support and rhino support. + A test suite is supplied for the browser plugin. It can be built using 'make plugin-tests' and run by loading the HTML page specified into a browser with the plugin installed. From omajid at redhat.com Fri Apr 8 07:21:42 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 08 Apr 2011 10:21:42 -0400 Subject: [icedtea-web] RFC: add unit tests for the jnlp parser In-Reply-To: <20110407234951.GB32676@rivendell.middle-earth.co.uk> References: <20110330220857.GH6143@rivendell.middle-earth.co.uk> <4D93C5ED.5000501@redhat.com> <20110331002116.GO6143@rivendell.middle-earth.co.uk> <4D94BC8E.5020301@redhat.com> <20110331182651.GE6143@rivendell.middle-earth.co.uk> <4D94D654.3020306@redhat.com> <20110331205614.GI6143@rivendell.middle-earth.co.uk> <4D964998.5010807@redhat.com> <20110405121241.GA2799@shelob.middle-earth.co.uk> <4D9B28E3.4020600@redhat.com> <20110407234951.GB32676@rivendell.middle-earth.co.uk> Message-ID: <4D9F19F6.3060307@redhat.com> On 04/07/2011 07:49 PM, Dr Andrew John Hughes wrote:>>>> +A custom JUnit ouput formatter is supplied. This makes the output of JUnit >>>> +tests match the output of other tests. A simple 'Passed:' or 'FAILED:' is >>>> +printed out, followed by.. This is also the format used >>>> +by JTreg. >> > > Ok, looks good. Please commit. > Done. Thanks for reviewing it. Cheers, Omair From bugzilla-daemon at icedtea.classpath.org Fri Apr 8 11:11:53 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 08 Apr 2011 18:11:53 +0000 Subject: [Bug 688] icedtea6-1.10.1: OpenJDK Shark VM is unable to build itself on ppc In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=688 acrux @ cruxppc.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |acrux at linuxmail.org --- Comment #8 from acrux @ cruxppc.org 2011-04-08 18:11:53 --- (In reply to comment #6) > > > > Anyway is that old LLVM workaround still needed on PowerPC ? > If the old LLVM workaround = building for ppc32 then YES, this are still > needed: > 20 CONF="--with-cxx-include-32bit-dir=32" > Building LLVM for ppc64 are still unsupported by the 2.9 release. > see: http://llvm.org/bugs/show_bug.cgi?id=9529 > that old patch doesn't cleanly apply due a deep change in lib/Target/PowerPC/PPCISelLowering.cpp and i'm not involved in llvm development to work on and rediff it. I also tried a llvm built with -mlongcall but didn't help. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From xerxes at zafena.se Fri Apr 8 13:48:24 2011 From: xerxes at zafena.se (Xerxes Ranby) Date: Fri, 08 Apr 2011 22:48:24 +0200 Subject: OpenWrt/backfire + IcedTea + mips? In-Reply-To: <1302265181.4950.23.camel@master.home> References: <1302265181.4950.23.camel@master.home> Message-ID: <4D9F7498.1010509@zafena.se> On 2011-04-08 14:19, John Connett wrote: > Anyone tried this combination? Any comments? > We need to add cross compilation support inside OpenJDK upstream or provided it from inside IcedTea in order to get IcedTea built by OpenWrt. You can find a summary of things needed to be done here: https://blueprints.launchpad.net/linaro/+spec/java-crosscompiling-openjdk ... and of course integrate it all into OpenWRT so that you can select and add IcedTea/OpenJDK from the OpenWRT configure Languages/Utilities section. > On my potential target: > # cat /proc/cpuinfo > system type : Atheros AR9132 rev 2 > machine : Buffalo WZR-HP-G300NH The Buffalo with 64Mb of RAM will be able to run some applications using OpenJDK fine. The limited 32Mb of flash ROM storage will be a problem because OpenJDK needs glibc and thus the base system will need a quite large footprint. You can reduce the footprint somewhat by using eglibc. Also OpenJDK itself are massive and usually consumes around 140Mb. If you put OpenJDK on a USB memory stick and occupy the USB port on the Buffalo then you will be fine. If you use IcedTea to build OpenJDK then you can get a fast JVM with JIT running by building IcedTea using the --enable-cacao or --enable-jamvm configure options. The IcedTea project are also hosting a brand new mips Hotspot JIT source repository that needs to be built and tested. This mips port was made to speed up OpenJDK for the Longsoon mips64, i do not know if it will work on mips32 but if it do then it are probably the fastest mips jvm port out there. http://icedtea.classpath.org/hg/openjdk6-mips Try to run prebuilt Debian mipsel openjdk binarys from inside your OpenWRT system to find out if the current available jvm's runs your intended applications fast enough and without hitting any out-of-memory senarios. > processor : 0 > cpu model : MIPS 24Kc V7.4 > BogoMIPS : 266.24 > wait instruction : yes > microsecond timers : yes > tlb_entries : 16 > extra interrupt vector : yes > hardware watchpoint : yes, count: 4, address/irw mask: [0x0000, > 0x0000, 0x0020, 0x0048] > ASEs implemented : mips16 > shadow register sets : 1 > core : 0 > VCED exceptions : not available > VCEI exceptions : not available Cheers Xerxes From omajid at redhat.com Fri Apr 8 14:28:37 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 08 Apr 2011 17:28:37 -0400 Subject: [icedtea-web] RFC: add a new autoconf macro IT_FIND_OPTIONAL_JAR In-Reply-To: <4D769F26.4090808@redhat.com> References: <4D764EEC.4060705@redhat.com> <20110308173308.GH2877@rivendell.middle-earth.co.uk> <4D7675D8.6060804@redhat.com> <20110308210505.GK2877@rivendell.middle-earth.co.uk> <4D769F26.4090808@redhat.com> Message-ID: <4D9F7E05.1070807@redhat.com> On 03/08/2011 04:27 PM, Omair Majid wrote: > > Looks like a bug to me. Removing rhino and attempting to build icedtea6 > (HEAD) fails: > > $ sudo rpm -e --nodeps rhino > $ ./autogen.sh && ./configure --disable-bootstrap > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > .... snip .... > checking if a native2ascii binary was specified... no > checking if /usr/lib/jvm/java-openjdk/bin/native2ascii is a valid > executable... yes > checking whether to include Javascript support via Rhino... not found > configure: error: "A rhino jar was not found in /usr/share/java as > either rhino.jar or js.jar." > > But explicitly saying --with-rhino=no works: > > $ ./autogen.sh && ./configure --with-rhino=no --disable-bootstrap > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > ...snip... > checking if /usr/lib/jvm/java-openjdk/bin/native2ascii is a valid > executable... yes > checking whether to include Javascript support via Rhino... no > checking for an OpenJDK source zip... not specified > .... snip .... > > The attached patch (for icedtea6 HEAD) is the fix I have used in > icedtea-web. Or I can add IT_FIND_OPTIONAL_JAR to icedtea{6,7}, if you > would prefer that. > Ping. Is this worth fixing in IcedTea6? Cheers, Omair From omajid at redhat.com Fri Apr 8 14:30:01 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 08 Apr 2011 17:30:01 -0400 Subject: [RFC][Icedtea-Web]: Ensure all ports entered are numeric values In-Reply-To: <110314578.458395.1302271927054.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <110314578.458395.1302271927054.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4D9F7E59.4030505@redhat.com> On 04/08/2011 10:12 AM, Andrew Su wrote: > Bah, here's the patch. > Since I suggested this, I dont know if I should review this ;) Still, it looks fine to me. Cheers, Omair From ahughes at redhat.com Fri Apr 8 16:23:33 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Sat, 9 Apr 2011 00:23:33 +0100 Subject: [icedtea-web] RFC: add a new autoconf macro IT_FIND_OPTIONAL_JAR In-Reply-To: <4D9F7E05.1070807@redhat.com> References: <4D764EEC.4060705@redhat.com> <20110308173308.GH2877@rivendell.middle-earth.co.uk> <4D7675D8.6060804@redhat.com> <20110308210505.GK2877@rivendell.middle-earth.co.uk> <4D769F26.4090808@redhat.com> <4D9F7E05.1070807@redhat.com> Message-ID: <20110408232331.GA27142@rivendell.middle-earth.co.uk> On 17:28 Fri 08 Apr , Omair Majid wrote: > On 03/08/2011 04:27 PM, Omair Majid wrote: > > > > Looks like a bug to me. Removing rhino and attempting to build icedtea6 > > (HEAD) fails: > > > > $ sudo rpm -e --nodeps rhino > > $ ./autogen.sh && ./configure --disable-bootstrap > > checking for a BSD-compatible install... /usr/bin/install -c > > checking whether build environment is sane... yes > > .... snip .... > > checking if a native2ascii binary was specified... no > > checking if /usr/lib/jvm/java-openjdk/bin/native2ascii is a valid > > executable... yes > > checking whether to include Javascript support via Rhino... not found > > configure: error: "A rhino jar was not found in /usr/share/java as > > either rhino.jar or js.jar." > > > > But explicitly saying --with-rhino=no works: > > > > $ ./autogen.sh && ./configure --with-rhino=no --disable-bootstrap > > checking for a BSD-compatible install... /usr/bin/install -c > > checking whether build environment is sane... yes > > ...snip... > > checking if /usr/lib/jvm/java-openjdk/bin/native2ascii is a valid > > executable... yes > > checking whether to include Javascript support via Rhino... no > > checking for an OpenJDK source zip... not specified > > .... snip .... > > > > The attached patch (for icedtea6 HEAD) is the fix I have used in > > icedtea-web. Or I can add IT_FIND_OPTIONAL_JAR to icedtea{6,7}, if you > > would prefer that. > > > > Ping. Is this worth fixing in IcedTea6? > > Cheers, > Omair Is what worth fixing? This sounds like the correct behaviour. Rhino is on by default. If you want to build without, --without-rhino works. - Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Fri Apr 8 16:27:18 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Sat, 9 Apr 2011 00:27:18 +0100 Subject: Question about IcedTea6 1.9.7 + Webstart (NetX) + OSGI In-Reply-To: <4D9EAE2E.10500@gmx.de> References: <4D9C10E2.1040000@gmx.de> <4D9C2716.4080603@redhat.com> <4D9D83C3.60006@gmx.de> <1302169120.9107.13.camel@springer.wildebeest.org> <20110408004057.GH32676@rivendell.middle-earth.co.uk> <4D9EAE2E.10500@gmx.de> Message-ID: <20110408232718.GB27142@rivendell.middle-earth.co.uk> On 08:41 Fri 08 Apr , Adalbert Prokop wrote: > On 08.04.2011 02:40, Dr Andrew John Hughes wrote: > > On 11:38 Thu 07 Apr , Mark Wielaard wrote: > >> On Thu, 2011-04-07 at 11:28 +0200, Adalbert Prokop wrote: > > >> There is a real bugzilla at http://icedtea.classpath.org/bugzilla > > > Yes, the one Mark mentions. The IcedTea JNLP support is a completely > > independent implementation. Sun/Oracle never released their code > > as FOSS. > > Yes, thank you for pointing out. I was searching for "Bugzilla" and > "OpenJDK", which led me to http://bugs.openjdk.java.net. Once there you > can find a pointer to Sun/Oracle's bug report service - the confusion > was complete. > > It's a challenge of its own to find the right site for the various > components. > Yeah, the problem there is the search term 'OpenJDK'. The plugin and Web Start support in IcedTea have nothing to do with OpenJDK. > -- > best wishes > Adalbert -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From gnu_andrew at member.fsf.org Fri Apr 8 17:15:49 2011 From: gnu_andrew at member.fsf.org (Dr Andrew John Hughes) Date: Sat, 9 Apr 2011 01:15:49 +0100 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> Message-ID: It makes sense to include the distro-pkg-dev list on this discussion rather than keeping it hidden away on this list that most distro vendors won't be on. CCing it. On 4 April 2011 02:51, Robert Ottenhag wrote: > > I am about to improve the identification of popular Linux distros during dumping, see bug [1] and [2], that states that we should "correctly identify Ubuntu as the operating system in crash report instead of 'Debian'". > > > > I am somewhat reluctant to directly apply the suggested patch though which only adds to the existing problematic implementation where some distros not are identified at all, or are identified as a different distro. > > > > The current implementation [4] relies on the fact that most Linux distros have /etc/XXX-release files, where some distros have multiple files (see [3]). It then checks a fixed set of these files in order, and stops at the first matching file, so the order is important. > > > > (0) the current order is "/etc/mandrake-release", "/etc/sun-release", "/etc/redhat-release", "/etc/SuSE-release", "/etc/turbolinux-release", "/etc/gentoo-release", "/etc/debian_version", "/etc/ltib-release", "/etc/angstrom-version", and the proposed patch is to insert "/etc/lsb-release" right before "/etc/debian_version". > > > > If we instead of (0) replace it by (1) and (2) below it will be improved in many ways. > > > > (1) call the "lsb_release" tool, if it exists, which returns distro specific info based on either /etc/lsb_release or /etc/XXX-release, and that also knows which of multiple /etc/XXX-release files to check first, e.g. /etc/enterprise-linux before /etc/redhat-linux. > This also won't work if the tool isn't installed. Most of the time, it isn't. We found this when support was added to IcedTea to use its content in the HotSpot crash dump and added it as a dependency in distro packages as a result. > > > (2) list all /etc/*-release and /etc/*_version files, headed by the respective file names > That would appear to create a lot of empty fields with no information. > > > The problem with (1) is that it calls an external process during a phase with might be very critical on resources, and it might not be available on specific old or embedded distros.? Thus we still need (2) for which we need to verify that directory listing does not violate similar resource contraints.? Regarding (2) the order of listed files should also be considered if it simplifies parsing of the dump output. > > > > The new solution would look something like > > ? OS: > > ??? /etc/debian_version > > ?????? > > ??? /etc/lsb-release > > ?????? > > > > Fundamentally, instead of having the JVM to try identify the Linux distro, it becomes up to the reader/parser of the dump output, but with the benefit of having all data available. > I really don't see why the current solution is such a problem. This sounds like it's just going to make the output messy. > > > References: > > > > [1] https://bugs.openjdk.java.net/show_bug.cgi?id=100137 > > [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6986195 > > [3] http://linuxmafia.com/faq/Admin/release-files.html > > [4] hotspot/src/os/linux/vm/os_linux.cpp:os::print_os_info(). > > > > I appreciate any comments and ideas. > > > > Thanks > > > > /Robert > > > > -- > > Robert Ottenhag | Senior Member of Technical Staff > Phone: +46850630961 | | Fax: +46850630911 | | Mobile: +46707106161 > Oracle Oracle Java VM > ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm > > Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 > > Oracle is committed to developing practices and products that help protect the environment > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D ?0698 0713 C3ED F586 2A37 From pcpa at mandriva.com.br Fri Apr 8 20:47:07 2011 From: pcpa at mandriva.com.br (Paulo =?iso-8859-1?Q?C=E9sar_Pereira_de_Andrade?=) Date: Sat, 9 Apr 2011 00:47:07 -0300 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> Message-ID: Dr Andrew John Hughes wrote: > It makes sense to include the distro-pkg-dev list on this discussion > rather than keeping it hidden away on this list that most distro > vendors won't be on. CCing it. > > On 4 April 2011 02:51, Robert Ottenhag wrote: >> >> I am about to improve the identification of popular Linux distros during >> dumping, see bug [1] and [2], that states that we should "correctly >> identify Ubuntu as the operating system in crash report instead of >> 'Debian'". >> >> >> >> I am somewhat reluctant to directly apply the suggested patch though >> which only adds to the existing problematic implementation where some >> distros not are identified at all, or are identified as a different >> distro. >> >> >> >> The current implementation [4] relies on the fact that most Linux >> distros have /etc/XXX-release files, where some distros have multiple >> files (see [3]). It then checks a fixed set of these files in order, and >> stops at the first matching file, so the order is important. >> >> >> >> (0) the current order is "/etc/mandrake-release", "/etc/sun-release", >> "/etc/redhat-release", "/etc/SuSE-release", "/etc/turbolinux-release", >> "/etc/gentoo-release", "/etc/debian_version", "/etc/ltib-release", >> "/etc/angstrom-version", and the proposed patch is to insert >> "/etc/lsb-release" right before "/etc/debian_version". I think in mandrake, conectiva and madriva, /etc/redhat-release has been always a symlink to, mandrake-release or conectiva-release, and lately, mandriva-release, so, order of search is not important. The lsb solution would require adding a requires, e.g: $ urpmq --whatrequires lsb-release cfengine3-base codeina dkms-minimal facter gnome-system-monitor lsb-release perl-Sys-Info-Driver-Linux smolt vodafone-mobile-connect xbmc (urpmq tells about software not installed) $ cat /etc/redhat-release Mandriva Linux release 2011.0 (Cooker) for x86_64 >> If we instead of (0) replace it by (1) and (2) below it will be improved >> in many ways. >> >> >> >> (1) call the "lsb_release" tool, if it exists, which returns distro >> specific info based on either /etc/lsb_release or /etc/XXX-release, and >> that also knows which of multiple /etc/XXX-release files to check first, >> e.g. /etc/enterprise-linux before /etc/redhat-linux. >> > > This also won't work if the tool isn't installed. Most of the time, > it isn't. We found this when support was added to IcedTea to use its > content in the HotSpot crash dump and added it as a dependency in > distro packages as a result. > >> >> >> (2) list all /etc/*-release and /etc/*_version files, headed by the >> respective file names >> > > That would appear to create a lot of empty fields with no information. > >> >> >> The problem with (1) is that it calls an external process during a phase >> with might be very critical on resources, and it might not be available >> on specific old or embedded distros.?? Thus we still need (2) for which >> we need to verify that directory listing does not violate similar >> resource contraints.?? Regarding (2) the order of listed files should >> also be considered if it simplifies parsing of the dump output. >> >> >> >> The new solution would look something like >> >> ?? OS: >> >> ?????? /etc/debian_version >> >> ???????????? >> >> ?????? /etc/lsb-release >> >> ???????????? >> >> >> >> Fundamentally, instead of having the JVM to try identify the Linux >> distro, it becomes up to the reader/parser of the dump output, but with >> the benefit of having all data available. >> > > I really don't see why the current solution is such a problem. This > sounds like it's just going to make the output messy. > >> >> >> References: >> >> >> >> [1] https://bugs.openjdk.java.net/show_bug.cgi?id=100137 >> >> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6986195 >> >> [3] http://linuxmafia.com/faq/Admin/release-files.html >> >> [4] hotspot/src/os/linux/vm/os_linux.cpp:os::print_os_info(). >> >> >> >> I appreciate any comments and ideas. I think most information that matters is already available via uname (syscall or utility), or would need to be requested to properly handle a bug report. E.g. $ uname -srm Linux 2.6.38.2-desktop-1mnb x86_64 >> Thanks >> >> >> >> /Robert Paulo From bugzilla-daemon at icedtea.classpath.org Sun Apr 10 03:07:38 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 10 Apr 2011 10:07:38 +0000 Subject: [Bug 691] New: icedtea fails to compile netbeans Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=691 Summary: icedtea fails to compile netbeans Product: IcedTea Version: 6-1.10.1 Platform: all URL: http://netbeans.org/bugzilla/show_bug.cgi?id=197275 OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: IcedTea6 AssignedTo: unassigned at icedtea.classpath.org ReportedBy: fordfrog at gentoo.org the issue is described in more detail at http://netbeans.org/bugzilla/show_bug.cgi?id=197275 summary of the issue: - icedtea 6.1.10+ fails to compile netbeans 7.0 rc2 (http://dlc.sun.com.edgesuite.net/netbeans/7.0/rc2/zip/netbeans-7.0rc2-201104070802-src.zip) - icedtea <6.1.10 compiles it fine - icedtea icedtea-7.1.13 fails to compile it too - any icedtea version mentioned compiles fine netbeans trunk (http://bits.netbeans.org/download/trunk/nightly/2011-04-09_04-01-10/zip/netbeans-trunk-nightly-201104090401-src.zip) - sun-jdk compiles any mentioned netbeans version without error the error is this: jar: [jarwithmoduleattributes] Computed OpenIDE-Module-Specification-Version: 1.12.1.1.17 [jarwithmoduleattributes] Building jar: /var/tmp/portage/netbeans/nbbuild/netbeans/java/modules/org-netbeans-modules-java-source-ant.jar nblib: [mkdir] Created dir: /var/tmp/portage/netbeans/java.source.ant/build/antclasses [javac] Compiling 3 source files to /var/tmp/portage/netbeans/java.source.ant/build/antclasses [repeat] /var/tmp/portage/netbeans/java.source.ant/antsrc/org/netbeans/modules/java/source/ant/JavacTask.java:111: package CheckForCleanBuilds does not exist [repeat] if (CheckForCleanBuilds.cleanBuild.get() && getSrcdir() != null) { [repeat] ^ [repeat] 1 error [nbmerge] Failed to build target: all-java.source.ant BUILD FAILED /var/tmp/portage/netbeans/nbbuild/build.xml:382: The following error occurred while executing this line: /var/tmp/portage/netbeans/nbbuild/build.xml:377: The following error occurred while executing this line: /var/tmp/portage/netbeans/nbbuild/build.xml:412: The following error occurred while executing this line: /var/tmp/portage/netbeans/nbbuild/build.xml:395: The following error occurred while executing this line: /var/tmp/portage/netbeans/nbbuild/build.xml:377: The following error occurred while executing this line: /var/tmp/portage/netbeans/nbbuild/build.xml:424: The following error occurred while executing this line: /var/tmp/portage/netbeans/java.source.ant/build.xml:52: Compile failed; see the compiler error output for details. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From mjw at icedtea.classpath.org Sun Apr 10 13:58:09 2011 From: mjw at icedtea.classpath.org (mjw at icedtea.classpath.org) Date: Sun, 10 Apr 2011 20:58:09 +0000 Subject: /hg/icedtea6: Fix missing clazz argument to all hotspot.jni.Call... Message-ID: changeset ddd219edd416 in /hg/icedtea6 details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=ddd219edd416 author: Mark Wielaard date: Sun Apr 10 22:51:11 2011 +0200 Fix missing clazz argument to all hotspot.jni.CallNonvirtual* stap probes. 2011-04-10 Yasumasa Suenaga * tapset/hotspot_jni.stp.in (hotspot.jni.CallNonvirtual*): Add missing clazz argument to all probes. Fix methodid to be last argument. Add clazz to probestr. diffstat: ChangeLog | 6 + tapset/hotspot_jni.stp.in | 180 ++++++++++++++++++++++++++++++--------------- 2 files changed, 126 insertions(+), 60 deletions(-) diffs (truncated from 616 to 500 lines): diff -r 0239a181c7a0 -r ddd219edd416 ChangeLog --- a/ChangeLog Thu Mar 31 19:23:12 2011 -0400 +++ b/ChangeLog Sun Apr 10 22:51:11 2011 +0200 @@ -1,3 +1,9 @@ +2011-04-10 Yasumasa Suenaga + + * tapset/hotspot_jni.stp.in (hotspot.jni.CallNonvirtual*): + Add missing clazz argument to all probes. Fix methodid + to be last argument. Add clazz to probestr. + 2011-03-31 Deepak Bhole S7031385, PR680: Incorrect register allocation in diff -r 0239a181c7a0 -r ddd219edd416 tapset/hotspot_jni.stp.in --- a/tapset/hotspot_jni.stp.in Thu Mar 31 19:23:12 2011 -0400 +++ b/tapset/hotspot_jni.stp.in Sun Apr 10 22:51:11 2011 +0200 @@ -1067,6 +1067,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualBooleanMethodA = @@ -1076,8 +1077,9 @@ name = "CallNonvirtualBooleanMethodA" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualBooleanMethodA.return @@ -1099,6 +1101,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualBooleanMethod = @@ -1108,8 +1111,9 @@ name = "CallNonvirtualBooleanMethod" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualBooleanMethod.return @@ -1131,6 +1135,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualBooleanMethodV = @@ -1140,8 +1145,9 @@ name = "CallNonvirtualBooleanMethodV" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualBooleanMethodV.return @@ -1163,6 +1169,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualByteMethodA = @@ -1172,8 +1179,9 @@ name = "CallNonvirtualByteMethodA" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualByteMethodA.return @@ -1195,6 +1203,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualByteMethod = @@ -1204,8 +1213,9 @@ name = "CallNonvirtualByteMethod" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualByteMethod.return @@ -1227,6 +1237,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualByteMethodV = @@ -1236,8 +1247,9 @@ name = "CallNonvirtualByteMethodV" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualByteMethodV.return @@ -1259,6 +1271,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualCharMethodA = @@ -1268,8 +1281,9 @@ name = "CallNonvirtualCharMethodA" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualCharMethodA.return @@ -1291,6 +1305,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualCharMethod = @@ -1300,8 +1315,9 @@ name = "CallNonvirtualCharMethod" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualCharMethod.return @@ -1323,6 +1339,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualCharMethodV = @@ -1332,8 +1349,9 @@ name = "CallNonvirtualCharMethodV" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualCharMethodV.return @@ -1355,6 +1373,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualDoubleMethodA = @@ -1364,8 +1383,9 @@ name = "CallNonvirtualDoubleMethodA" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualDoubleMethodA.return @@ -1384,6 +1404,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualDoubleMethod = @@ -1393,8 +1414,9 @@ name = "CallNonvirtualDoubleMethod" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualDoubleMethod.return @@ -1413,6 +1435,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualDoubleMethodV = @@ -1422,8 +1445,9 @@ name = "CallNonvirtualDoubleMethodV" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualDoubleMethodV.return @@ -1442,6 +1466,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualFloatMethodA = @@ -1451,8 +1476,9 @@ name = "CallNonvirtualFloatMethodA" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualFloatMethodA.return @@ -1471,6 +1497,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualFloatMethod = @@ -1480,8 +1507,9 @@ name = "CallNonvirtualFloatMethod" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualFloatMethod.return @@ -1500,6 +1528,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualFloatMethodV = @@ -1509,8 +1538,9 @@ name = "CallNonvirtualFloatMethodV" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualFloatMethodV.return @@ -1529,6 +1559,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualIntMethodA = @@ -1538,8 +1569,9 @@ name = "CallNonvirtualIntMethodA" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualIntMethodA.return @@ -1561,6 +1593,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualIntMethod = @@ -1570,8 +1603,9 @@ name = "CallNonvirtualIntMethod" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualIntMethod.return @@ -1593,6 +1627,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualIntMethodV = @@ -1602,8 +1637,9 @@ name = "CallNonvirtualIntMethodV" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualIntMethodV.return @@ -1625,6 +1661,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualLongMethodA = @@ -1634,8 +1671,9 @@ name = "CallNonvirtualLongMethodA" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualLongMethodA.return @@ -1657,6 +1695,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualLongMethod = @@ -1666,8 +1705,9 @@ name = "CallNonvirtualLongMethod" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualLongMethod.return @@ -1689,6 +1729,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualLongMethodV = @@ -1698,8 +1739,9 @@ name = "CallNonvirtualLongMethodV" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualLongMethodV.return @@ -1721,6 +1763,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualObjectMethodA = @@ -1730,8 +1773,9 @@ name = "CallNonvirtualObjectMethodA" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualObjectMethodA.return @@ -1753,6 +1797,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualObjectMethod = @@ -1762,8 +1807,9 @@ name = "CallNonvirtualObjectMethod" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualObjectMethod.return @@ -1785,6 +1831,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. + * clazz - jclass reference. * methodid - ID of the method to call. */ probe hotspot.jni.CallNonvirtualObjectMethodV = @@ -1794,8 +1841,9 @@ name = "CallNonvirtualObjectMethodV" env = $arg1 obj = $arg2 - methodid = $arg3 - probestr = sprintf("%s(env=0x%x,obj=0x%x,methodid=0x%x)", name, env, obj, methodid) + clazz = $arg3 + methodid = $arg4 + probestr = sprintf("%s(env=0x%x,obj=0x%x,clazz=0x%x,methodid=0x%x)", name, env, obj, clazz, methodid) } /* hotspot.jni.CallNonvirtualObjectMethodV.return @@ -1817,6 +1865,7 @@ * * env - JNIEnv pointer. * obj - jobject reference. From mark at klomp.org Sun Apr 10 14:00:22 2011 From: mark at klomp.org (Mark Wielaard) Date: Sun, 10 Apr 2011 23:00:22 +0200 Subject: JNI functions "CallNonvirtual*" probe is incorrect In-Reply-To: <4D9D833C.9050205@oss.ntt.co.jp> References: <4D9D66B7.7060803@oss.ntt.co.jp> <1302166932.9107.12.camel@springer.wildebeest.org> <4D9D833C.9050205@oss.ntt.co.jp> Message-ID: <1302469222.5256.17.camel@springer.wildebeest.org> Hi Yasumasa, On Thu, 2011-04-07 at 18:26 +0900, Yasumasa Suenaga wrote: > I wish that my patch pass your test :-) Your patch worked beautifully for me. Thanks again. Pushed as: changeset: 2532:ddd219edd416 tag: tip user: Mark Wielaard date: Sun Apr 10 22:51:11 2011 +0200 files: ChangeLog tapset/hotspot_jni.stp.in description: Fix missing clazz argument to all hotspot.jni.CallNonvirtual* stap probes. 2011-04-10 Yasumasa Suenaga * tapset/hotspot_jni.stp.in (hotspot.jni.CallNonvirtual*): Add missing clazz argument to all probes. Fix methodid to be last argument. Add clazz to probestr. Cheers, Mark From thebohemian at gmx.net Mon Apr 11 01:19:53 2011 From: thebohemian at gmx.net (Robert Schuster) Date: Mon, 11 Apr 2011 10:19:53 +0200 Subject: OpenWrt/backfire + IcedTea + mips? In-Reply-To: <4D9F7498.1010509@zafena.se> References: <1302265181.4950.23.camel@master.home> <4D9F7498.1010509@zafena.se> Message-ID: <4DA2B9A9.8070408@gmx.net> Hi, Am 08.04.2011 22:48, schrieb Xerxes Ranby: > On 2011-04-08 14:19, John Connett wrote: >> Anyone tried this combination? Any comments? No, but the Zero port should work. There are also ucLibc compatibility patches in OpenEmbedded's OpenJDK build recipes. At the moment we're lacking the resources to make them nice for an IcedTea inclusion but if someone else wants to pick that task up. Go ahead! Regards, Robert -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110411/764bd060/signature.asc From jvanek at icedtea.classpath.org Mon Apr 11 06:13:14 2011 From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org) Date: Mon, 11 Apr 2011 13:13:14 +0000 Subject: /hg/icedtea-web: removed junit Message-ID: changeset 4f195bca0dc8 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=4f195bca0dc8 author: Jiri Vanek date: Mon Apr 11 15:08:01 2011 +0200 removed junit diffstat: ChangeLog | 4 ++ Makefile.am | 87 ++--------------------------------------------------------- configure.ac | 2 - 3 files changed, 7 insertions(+), 86 deletions(-) diffs (152 lines): diff -r e7c791aa1bd2 -r 4f195bca0dc8 ChangeLog --- a/ChangeLog Fri Apr 08 10:17:36 2011 -0400 +++ b/ChangeLog Mon Apr 11 15:08:01 2011 +0200 @@ -1,3 +1,7 @@ +2011-04-11 Jiri Vanek + + * removed junit (1/2 from mooving to testNG) + 2011-04-08 Omair Majid * README: Update to add notes on rhino and junit. diff -r e7c791aa1bd2 -r 4f195bca0dc8 Makefile.am --- a/Makefile.am Fri Apr 08 10:17:36 2011 -0400 +++ b/Makefile.am Mon Apr 11 15:08:01 2011 +0200 @@ -6,17 +6,6 @@ NETX_EXTRA_DIR=$(abs_top_srcdir)/extra/net/sourceforge/javaws/about/resources NETX_EXTRA_DIST_DIR=$(abs_top_builddir)/extra-lib/net/sourceforge/javaws/about/resources -TESTS_SRCDIR=$(abs_top_srcdir)/tests -TESTS_DIR=$(abs_top_builddir)/tests.build - -NETX_UNIT_TEST_SRCDIR=$(TESTS_SRCDIR)/netx/unit -NETX_UNIT_TEST_DIR=$(TESTS_DIR)/netx/unit - -JUNIT_RUNNER_DIR=$(TESTS_DIR)/junit-runner -JUNIT_RUNNER_SRCDIR=$(TESTS_SRCDIR)/junit-runner - -JUNIT_RUNNER_JAR=$(abs_top_builddir)/junit-runner.jar - # Build directories BOOT_DIR = $(abs_top_builddir)/bootstrap/jdk1.6.0 @@ -91,19 +80,6 @@ endif endif -if WITH_RHINO - RHINO_TESTS=check-pac-functions -else - RHINO_TESTS= -endif - -if WITH_JUNIT - JUNIT_TESTS=run-netx-unit-tests -else - JUNIT_TESTS= -endif - - PLUGIN_VERSION = IcedTea-Web $(FULL_VERSION) EXTRA_DIST = $(top_srcdir)/netx $(top_srcdir)/plugin javaws.png javaws.desktop.in extra launcher \ @@ -124,7 +100,7 @@ all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/javaws \ javaws.desktop stamps/docs.stamp launcher.build/itweb-settings itweb-settings.desktop -check-local: $(RHINO_TESTS) $(JUNIT_TESTS) +check-local: check-pac-functions clean-local: clean-netx clean-plugin clean-liveconnect clean-extra clean-bootstrap-directory \ clean-native-ecj clean-launchers clean-desktop-files clean-docs clean-tests @@ -134,8 +110,7 @@ .PHONY: clean-IcedTeaPlugin clean-add-netx clean-add-netx-debug clean-add-plugin clean-add-plugin-debug \ clean-bootstrap-directory clean-native-ecj clean-desktop-files clean-netx-docs clean-docs clean-plugin-docs \ - clean-tests check-local clean-launchers check-pac-functions run-netx-unit-tests clean-netx-tests \ - clean-junit-runner clean-netx-unit-tests + clean-tests check-local clean-launchers install-exec-local: ${mkinstalldirs} $(DESTDIR)$(bindir) $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/ $(DESTDIR)$(libdir) @@ -423,67 +398,11 @@ # check # ========================== -clean-tests: clean-netx-tests - if [ -e $(TESTS_DIR) ]; then \ - rmdir $(TESTS_DIR) ; \ - fi - check-pac-functions: stamps/bootstrap-directory.stamp ./jrunscript $(abs_top_srcdir)/tests/netx/pac/pac-funcs-test.js \ $$(readlink -f $(abs_top_srcdir)/netx/net/sourceforge/jnlp/runtime/pac-funcs.js) -junit-runner-source-files.txt: - find $(JUNIT_RUNNER_SRCDIR) -name '*.java' | sort > $@ - -$(JUNIT_RUNNER_JAR): junit-runner-source-files.txt - mkdir -p $(JUNIT_RUNNER_DIR) && \ - $(BOOT_DIR)/bin/javac $(IT_JAVACFLAGS) \ - -d $(JUNIT_RUNNER_DIR) \ - -classpath $(JUNIT_JAR) \ - @junit-runner-source-files.txt && \ - $(BOOT_DIR)/bin/jar cf $@ -C $(JUNIT_RUNNER_DIR) . - -netx-unit-tests-source-files.txt: - find $(NETX_UNIT_TEST_SRCDIR) -name '*.java' | sort > $@ - -stamps/netx-unit-tests-compile.stamp: stamps/netx.stamp \ - netx-unit-tests-source-files.txt - mkdir -p $(NETX_UNIT_TEST_DIR) && \ - $(BOOT_DIR)/bin/javac $(IT_JAVACFLAGS) \ - -d $(NETX_UNIT_TEST_DIR) \ - -classpath $(JUNIT_JAR):$(NETX_DIR)/lib/classes.jar \ - @netx-unit-tests-source-files.txt && \ - mkdir -p stamps && \ - touch $@ - -run-netx-unit-tests: stamps/netx-unit-tests-compile.stamp \ - $(JUNIT_RUNNER_JAR) - cp {$(NETX_UNIT_TEST_SRCDIR),$(NETX_UNIT_TEST_DIR)}/net/sourceforge/jnlp/basic.jnlp - cd $(NETX_UNIT_TEST_DIR) ; \ - class_names= ; \ - for test in `find -type f` ; do \ - class_name=`echo $$test | sed -e 's|\.class$$||' -e 's|^\./||'` ; \ - class_name=`echo $$class_name | sed -e 's|/|.|g' ` ; \ - class_names="$$class_names $$class_name" ; \ - done ; \ - echo $$class_names ; \ - CLASSPATH=$(NETX_DIR)/lib/classes.jar:$(JUNIT_JAR):$(JUNIT_RUNNER_JAR):. \ - $(BOOT_DIR)/bin/java -Xbootclasspath:$(RUNTIME) CommandLine $$class_names - -clean-netx-tests: clean-netx-unit-tests clean-junit-runner - if [ -e $(TESTS_DIR)/netx ]; then \ - rmdir $(TESTS_DIR)/netx ; \ - fi - -clean-junit-runner: - rm -f junit-runner-source-files.txt - rm -rf $(JUNIT_RUNNER_DIR) - rm -f $(JUNIT_RUNNER_JAR) - -clean-netx-unit-tests: - rm -f netx-unit-tests-source-files.txt - rm -rf $(NETX_UNIT_TEST_DIR) - rm -f stamps/netx-unit-tests-compile.stamp +-clean-tests: # plugin tests diff -r e7c791aa1bd2 -r 4f195bca0dc8 configure.ac --- a/configure.ac Fri Apr 08 10:17:36 2011 -0400 +++ b/configure.ac Mon Apr 11 15:08:01 2011 +0200 @@ -85,8 +85,6 @@ IT_FIND_OPTIONAL_JAR([rhino], RHINO, [/usr/share/java/js.jar /usr/share/rhino-1.6/lib/js.jar]) -IT_FIND_OPTIONAL_JAR([junit], JUNIT, - [/usr/share/java/junit4.jar]) AC_CONFIG_FILES([jrunscript], [chmod u+x jrunscript]) AC_CONFIG_FILES([build.properties]) From jvanek at icedtea.classpath.org Mon Apr 11 06:40:25 2011 From: jvanek at icedtea.classpath.org (jvanek at icedtea.classpath.org) Date: Mon, 11 Apr 2011 13:40:25 +0000 Subject: /hg/icedtea-web: added support for testng Message-ID: changeset 1cce62b89f07 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=1cce62b89f07 author: Jiri Vanek date: Mon Apr 11 15:36:10 2011 +0200 added support for testng diffstat: AUTHORS | 1 + ChangeLog | 4 + Makefile.am | 72 +++++++++++++++++++++++- acinclude.m4 | 7 ++ configure.ac | 6 ++ tests/netx/unit/net/sourceforge/jnlp/basic.jnlp | 11 +-- 6 files changed, 92 insertions(+), 9 deletions(-) diffs (203 lines): diff -r 4f195bca0dc8 -r 1cce62b89f07 AUTHORS --- a/AUTHORS Mon Apr 11 15:08:01 2011 +0200 +++ b/AUTHORS Mon Apr 11 15:36:10 2011 +0200 @@ -13,6 +13,7 @@ Jon A. Maxwell Andrew Su Joshua Sumali +Jiri Vanek Mark Wielaard Man Lung Wong diff -r 4f195bca0dc8 -r 1cce62b89f07 ChangeLog --- a/ChangeLog Mon Apr 11 15:08:01 2011 +0200 +++ b/ChangeLog Mon Apr 11 15:36:10 2011 +0200 @@ -1,3 +1,7 @@ +2011-04-11 Jiri Vanek + + * added testng support (2/2) + 2011-04-11 Jiri Vanek * removed junit (1/2 from mooving to testNG) diff -r 4f195bca0dc8 -r 1cce62b89f07 Makefile.am --- a/Makefile.am Mon Apr 11 15:08:01 2011 +0200 +++ b/Makefile.am Mon Apr 11 15:36:10 2011 +0200 @@ -6,6 +6,12 @@ NETX_EXTRA_DIR=$(abs_top_srcdir)/extra/net/sourceforge/javaws/about/resources NETX_EXTRA_DIST_DIR=$(abs_top_builddir)/extra-lib/net/sourceforge/javaws/about/resources +TESTS_DIR=$(abs_top_builddir)/tests.build +TESTS_SRCDIR=$(abs_top_srcdir)/tests + +NETX_UNIT_TEST_DIR=$(TESTS_DIR)/netx/unit +NETX_UNIT_TEST_SRCDIR=$(TESTS_SRCDIR)/netx/unit + # Build directories BOOT_DIR = $(abs_top_builddir)/bootstrap/jdk1.6.0 @@ -80,6 +86,23 @@ endif endif +if WITH_RHINO + RHINO_TESTS=check-pac-functions +else + RHINO_TESTS= +endif + +UNIT_TESTS= +if WITH_TESTNG +if WITH_QDOX +if WITH_BSH +if WITH_XSLT + UNIT_TESTS+=run-netx-unit-tests +endif +endif +endif +endif + PLUGIN_VERSION = IcedTea-Web $(FULL_VERSION) EXTRA_DIST = $(top_srcdir)/netx $(top_srcdir)/plugin javaws.png javaws.desktop.in extra launcher \ @@ -100,7 +123,7 @@ all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/javaws \ javaws.desktop stamps/docs.stamp launcher.build/itweb-settings itweb-settings.desktop -check-local: check-pac-functions +check-local: $(RHINO_TESTS) $(UNIT_TESTS) clean-local: clean-netx clean-plugin clean-liveconnect clean-extra clean-bootstrap-directory \ clean-native-ecj clean-launchers clean-desktop-files clean-docs clean-tests @@ -110,7 +133,8 @@ .PHONY: clean-IcedTeaPlugin clean-add-netx clean-add-netx-debug clean-add-plugin clean-add-plugin-debug \ clean-bootstrap-directory clean-native-ecj clean-desktop-files clean-netx-docs clean-docs clean-plugin-docs \ - clean-tests check-local clean-launchers + clean-tests check-local clean-launchers check-pac-functions run-netx-unit-tests clean-netx-tests \ + clean-netx-unit-tests install-exec-local: ${mkinstalldirs} $(DESTDIR)$(bindir) $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/ $(DESTDIR)$(libdir) @@ -398,11 +422,53 @@ # check # ========================== +clean-tests: clean-netx-tests + if [ -e $(TESTS_DIR) ]; then \ + rmdir $(TESTS_DIR) ; \ + fi + check-pac-functions: stamps/bootstrap-directory.stamp ./jrunscript $(abs_top_srcdir)/tests/netx/pac/pac-funcs-test.js \ $$(readlink -f $(abs_top_srcdir)/netx/net/sourceforge/jnlp/runtime/pac-funcs.js) --clean-tests: +netx-unit-tests-source-files.txt: + find $(NETX_UNIT_TEST_SRCDIR) -name '*.java' | sort > $@ + +stamps/netx-unit-tests-compile.stamp: stamps/netx.stamp \ + netx-unit-tests-source-files.txt + mkdir -p $(NETX_UNIT_TEST_DIR) + $(BOOT_DIR)/bin/javac $(IT_JAVACFLAGS) \ + -d $(NETX_UNIT_TEST_DIR) \ + -classpath $(TESTNG_JAR):$(NETX_DIR)/lib/classes.jar \ + @netx-unit-tests-source-files.txt + (cd $(NETX_UNIT_TEST_DIR) ; \ + $(BOOT_DIR)/bin/jar cf netx-tests.jar net) + mkdir -p stamps + touch $@ + +stamps/netx-unit-tests-update-jar.stamp: stamps/netx-unit-tests-compile.stamp + (cd $(NETX_UNIT_TEST_SRCDIR) ; \ + $(BOOT_DIR)/bin/jar uf $(NETX_UNIT_TEST_DIR)/netx-tests.jar \ + net/sourceforge/jnlp/basic.jnlp) + mkdir -p stamps + touch $@ + +run-netx-unit-tests: stamps/netx-unit-tests-update-jar.stamp + $(BOOT_DIR)/bin/java \ + -classpath $(NETX_UNIT_TEST_DIR)/netx-tests.jar:$(NETX_DIR)/lib/classes.jar:$(TESTNG_JAR):$(QDOX_JAR):$(BSH_JAR) \ + org.testng.TestNG -d $(NETX_UNIT_TEST_DIR)/tests-output $(NETX_UNIT_TEST_SRCDIR)/tests.xml || true + $(XSLT) $(abs_top_srcdir)/testng-to-jtreg.xslt $(NETX_UNIT_TEST_DIR)/tests-output/testng-results.xml + +clean-netx-tests: clean-netx-unit-tests + if [ -e $(TESTS_DIR)/netx ]; then \ + rmdir $(TESTS_DIR)/netx ; \ + fi + +clean-netx-unit-tests: + rm -f netx-unit-tests-source-files.txt + rm -rf $(NETX_UNIT_TEST_DIR) + rm -f stamps/netx-unit-tests-compile.stamp + rm -f stamps/netx-unit-tests-update-jar.stamp # plugin tests diff -r 4f195bca0dc8 -r 1cce62b89f07 acinclude.m4 --- a/acinclude.m4 Mon Apr 11 15:08:01 2011 +0200 +++ b/acinclude.m4 Mon Apr 11 15:36:10 2011 +0200 @@ -497,6 +497,13 @@ AC_SUBST([$1]) ]) +AC_DEFUN_ONCE([IT_FIND_OPTIONAL_PROG], +[ + AC_PATH_PROG([$1], [$2]) + AM_CONDITIONAL(WITH_$1, test x"$$1" != "x") + AC_SUBST([$1]) +]) + AC_DEFUN([IT_SET_ARCH_SETTINGS], [ case "${host_cpu}" in diff -r 4f195bca0dc8 -r 1cce62b89f07 configure.ac --- a/configure.ac Mon Apr 11 15:08:01 2011 +0200 +++ b/configure.ac Mon Apr 11 15:36:10 2011 +0200 @@ -85,6 +85,12 @@ IT_FIND_OPTIONAL_JAR([rhino], RHINO, [/usr/share/java/js.jar /usr/share/rhino-1.6/lib/js.jar]) +IT_FIND_OPTIONAL_JAR([testng], TESTNG, + [/usr/share/java/testng.jar]) +IT_FIND_OPTIONAL_JAR([qdox], QDOX) +IT_FIND_OPTIONAL_JAR([bsh], BSH) + +IT_FIND_OPTIONAL_PROG(XSLT, [xsltproc]) AC_CONFIG_FILES([jrunscript], [chmod u+x jrunscript]) AC_CONFIG_FILES([build.properties]) diff -r 4f195bca0dc8 -r 1cce62b89f07 tests/netx/unit/net/sourceforge/jnlp/basic.jnlp --- a/tests/netx/unit/net/sourceforge/jnlp/basic.jnlp Mon Apr 11 15:08:01 2011 +0200 +++ b/tests/netx/unit/net/sourceforge/jnlp/basic.jnlp Mon Apr 11 15:36:10 2011 +0200 @@ -1,11 +1,11 @@ - + - + - Large JNLP + Large JNLP The IcedTea Project one-line @@ -24,7 +24,7 @@ decription of related-content - + @@ -43,5 +43,4 @@ arg1 arg2 - - + From andrew at icedtea.classpath.org Mon Apr 11 08:04:11 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Mon, 11 Apr 2011 15:04:11 +0000 Subject: /hg/icedtea-web: 2 new changesets Message-ID: changeset 123f69dacbe4 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=123f69dacbe4 author: Andrew John Hughes date: Mon Apr 11 16:02:25 2011 +0100 Backed out changeset 1cce62b89f07 - unapproved patch changeset 934543b8084d in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=934543b8084d author: Andrew John Hughes date: Mon Apr 11 16:03:44 2011 +0100 Backout 4f195bca0dc8 - unapproved patch diffstat: AUTHORS | 1 - ChangeLog | 8 -- Makefile.am | 83 ++++++++++++++---------- acinclude.m4 | 7 -- configure.ac | 8 +- tests/netx/unit/net/sourceforge/jnlp/basic.jnlp | 11 +- 6 files changed, 57 insertions(+), 61 deletions(-) diffs (237 lines): diff -r 1cce62b89f07 -r 934543b8084d AUTHORS --- a/AUTHORS Mon Apr 11 15:36:10 2011 +0200 +++ b/AUTHORS Mon Apr 11 16:03:44 2011 +0100 @@ -13,7 +13,6 @@ Jon A. Maxwell Andrew Su Joshua Sumali -Jiri Vanek Mark Wielaard Man Lung Wong diff -r 1cce62b89f07 -r 934543b8084d ChangeLog --- a/ChangeLog Mon Apr 11 15:36:10 2011 +0200 +++ b/ChangeLog Mon Apr 11 16:03:44 2011 +0100 @@ -1,11 +1,3 @@ -2011-04-11 Jiri Vanek - - * added testng support (2/2) - -2011-04-11 Jiri Vanek - - * removed junit (1/2 from mooving to testNG) - 2011-04-08 Omair Majid * README: Update to add notes on rhino and junit. diff -r 1cce62b89f07 -r 934543b8084d Makefile.am --- a/Makefile.am Mon Apr 11 15:36:10 2011 +0200 +++ b/Makefile.am Mon Apr 11 16:03:44 2011 +0100 @@ -6,11 +6,16 @@ NETX_EXTRA_DIR=$(abs_top_srcdir)/extra/net/sourceforge/javaws/about/resources NETX_EXTRA_DIST_DIR=$(abs_top_builddir)/extra-lib/net/sourceforge/javaws/about/resources +TESTS_SRCDIR=$(abs_top_srcdir)/tests TESTS_DIR=$(abs_top_builddir)/tests.build -TESTS_SRCDIR=$(abs_top_srcdir)/tests +NETX_UNIT_TEST_SRCDIR=$(TESTS_SRCDIR)/netx/unit NETX_UNIT_TEST_DIR=$(TESTS_DIR)/netx/unit -NETX_UNIT_TEST_SRCDIR=$(TESTS_SRCDIR)/netx/unit + +JUNIT_RUNNER_DIR=$(TESTS_DIR)/junit-runner +JUNIT_RUNNER_SRCDIR=$(TESTS_SRCDIR)/junit-runner + +JUNIT_RUNNER_JAR=$(abs_top_builddir)/junit-runner.jar # Build directories @@ -92,16 +97,12 @@ RHINO_TESTS= endif -UNIT_TESTS= -if WITH_TESTNG -if WITH_QDOX -if WITH_BSH -if WITH_XSLT - UNIT_TESTS+=run-netx-unit-tests +if WITH_JUNIT + JUNIT_TESTS=run-netx-unit-tests +else + JUNIT_TESTS= endif -endif -endif -endif + PLUGIN_VERSION = IcedTea-Web $(FULL_VERSION) @@ -123,7 +124,7 @@ all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/javaws \ javaws.desktop stamps/docs.stamp launcher.build/itweb-settings itweb-settings.desktop -check-local: $(RHINO_TESTS) $(UNIT_TESTS) +check-local: $(RHINO_TESTS) $(JUNIT_TESTS) clean-local: clean-netx clean-plugin clean-liveconnect clean-extra clean-bootstrap-directory \ clean-native-ecj clean-launchers clean-desktop-files clean-docs clean-tests @@ -134,7 +135,7 @@ .PHONY: clean-IcedTeaPlugin clean-add-netx clean-add-netx-debug clean-add-plugin clean-add-plugin-debug \ clean-bootstrap-directory clean-native-ecj clean-desktop-files clean-netx-docs clean-docs clean-plugin-docs \ clean-tests check-local clean-launchers check-pac-functions run-netx-unit-tests clean-netx-tests \ - clean-netx-unit-tests + clean-junit-runner clean-netx-unit-tests install-exec-local: ${mkinstalldirs} $(DESTDIR)$(bindir) $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/ $(DESTDIR)$(libdir) @@ -431,44 +432,58 @@ ./jrunscript $(abs_top_srcdir)/tests/netx/pac/pac-funcs-test.js \ $$(readlink -f $(abs_top_srcdir)/netx/net/sourceforge/jnlp/runtime/pac-funcs.js) +junit-runner-source-files.txt: + find $(JUNIT_RUNNER_SRCDIR) -name '*.java' | sort > $@ + +$(JUNIT_RUNNER_JAR): junit-runner-source-files.txt + mkdir -p $(JUNIT_RUNNER_DIR) && \ + $(BOOT_DIR)/bin/javac $(IT_JAVACFLAGS) \ + -d $(JUNIT_RUNNER_DIR) \ + -classpath $(JUNIT_JAR) \ + @junit-runner-source-files.txt && \ + $(BOOT_DIR)/bin/jar cf $@ -C $(JUNIT_RUNNER_DIR) . + netx-unit-tests-source-files.txt: find $(NETX_UNIT_TEST_SRCDIR) -name '*.java' | sort > $@ stamps/netx-unit-tests-compile.stamp: stamps/netx.stamp \ - netx-unit-tests-source-files.txt - mkdir -p $(NETX_UNIT_TEST_DIR) + netx-unit-tests-source-files.txt + mkdir -p $(NETX_UNIT_TEST_DIR) && \ $(BOOT_DIR)/bin/javac $(IT_JAVACFLAGS) \ -d $(NETX_UNIT_TEST_DIR) \ - -classpath $(TESTNG_JAR):$(NETX_DIR)/lib/classes.jar \ - @netx-unit-tests-source-files.txt - (cd $(NETX_UNIT_TEST_DIR) ; \ - $(BOOT_DIR)/bin/jar cf netx-tests.jar net) - mkdir -p stamps + -classpath $(JUNIT_JAR):$(NETX_DIR)/lib/classes.jar \ + @netx-unit-tests-source-files.txt && \ + mkdir -p stamps && \ touch $@ -stamps/netx-unit-tests-update-jar.stamp: stamps/netx-unit-tests-compile.stamp - (cd $(NETX_UNIT_TEST_SRCDIR) ; \ - $(BOOT_DIR)/bin/jar uf $(NETX_UNIT_TEST_DIR)/netx-tests.jar \ - net/sourceforge/jnlp/basic.jnlp) - mkdir -p stamps - touch $@ +run-netx-unit-tests: stamps/netx-unit-tests-compile.stamp \ + $(JUNIT_RUNNER_JAR) + cp {$(NETX_UNIT_TEST_SRCDIR),$(NETX_UNIT_TEST_DIR)}/net/sourceforge/jnlp/basic.jnlp + cd $(NETX_UNIT_TEST_DIR) ; \ + class_names= ; \ + for test in `find -type f` ; do \ + class_name=`echo $$test | sed -e 's|\.class$$||' -e 's|^\./||'` ; \ + class_name=`echo $$class_name | sed -e 's|/|.|g' ` ; \ + class_names="$$class_names $$class_name" ; \ + done ; \ + echo $$class_names ; \ + CLASSPATH=$(NETX_DIR)/lib/classes.jar:$(JUNIT_JAR):$(JUNIT_RUNNER_JAR):. \ + $(BOOT_DIR)/bin/java -Xbootclasspath:$(RUNTIME) CommandLine $$class_names -run-netx-unit-tests: stamps/netx-unit-tests-update-jar.stamp - $(BOOT_DIR)/bin/java \ - -classpath $(NETX_UNIT_TEST_DIR)/netx-tests.jar:$(NETX_DIR)/lib/classes.jar:$(TESTNG_JAR):$(QDOX_JAR):$(BSH_JAR) \ - org.testng.TestNG -d $(NETX_UNIT_TEST_DIR)/tests-output $(NETX_UNIT_TEST_SRCDIR)/tests.xml || true - $(XSLT) $(abs_top_srcdir)/testng-to-jtreg.xslt $(NETX_UNIT_TEST_DIR)/tests-output/testng-results.xml - -clean-netx-tests: clean-netx-unit-tests +clean-netx-tests: clean-netx-unit-tests clean-junit-runner if [ -e $(TESTS_DIR)/netx ]; then \ rmdir $(TESTS_DIR)/netx ; \ fi +clean-junit-runner: + rm -f junit-runner-source-files.txt + rm -rf $(JUNIT_RUNNER_DIR) + rm -f $(JUNIT_RUNNER_JAR) + clean-netx-unit-tests: rm -f netx-unit-tests-source-files.txt rm -rf $(NETX_UNIT_TEST_DIR) rm -f stamps/netx-unit-tests-compile.stamp - rm -f stamps/netx-unit-tests-update-jar.stamp # plugin tests diff -r 1cce62b89f07 -r 934543b8084d acinclude.m4 --- a/acinclude.m4 Mon Apr 11 15:36:10 2011 +0200 +++ b/acinclude.m4 Mon Apr 11 16:03:44 2011 +0100 @@ -497,13 +497,6 @@ AC_SUBST([$1]) ]) -AC_DEFUN_ONCE([IT_FIND_OPTIONAL_PROG], -[ - AC_PATH_PROG([$1], [$2]) - AM_CONDITIONAL(WITH_$1, test x"$$1" != "x") - AC_SUBST([$1]) -]) - AC_DEFUN([IT_SET_ARCH_SETTINGS], [ case "${host_cpu}" in diff -r 1cce62b89f07 -r 934543b8084d configure.ac --- a/configure.ac Mon Apr 11 15:36:10 2011 +0200 +++ b/configure.ac Mon Apr 11 16:03:44 2011 +0100 @@ -85,12 +85,8 @@ IT_FIND_OPTIONAL_JAR([rhino], RHINO, [/usr/share/java/js.jar /usr/share/rhino-1.6/lib/js.jar]) -IT_FIND_OPTIONAL_JAR([testng], TESTNG, - [/usr/share/java/testng.jar]) -IT_FIND_OPTIONAL_JAR([qdox], QDOX) -IT_FIND_OPTIONAL_JAR([bsh], BSH) - -IT_FIND_OPTIONAL_PROG(XSLT, [xsltproc]) +IT_FIND_OPTIONAL_JAR([junit], JUNIT, + [/usr/share/java/junit4.jar]) AC_CONFIG_FILES([jrunscript], [chmod u+x jrunscript]) AC_CONFIG_FILES([build.properties]) diff -r 1cce62b89f07 -r 934543b8084d tests/netx/unit/net/sourceforge/jnlp/basic.jnlp --- a/tests/netx/unit/net/sourceforge/jnlp/basic.jnlp Mon Apr 11 15:36:10 2011 +0200 +++ b/tests/netx/unit/net/sourceforge/jnlp/basic.jnlp Mon Apr 11 16:03:44 2011 +0100 @@ -1,11 +1,11 @@ - + - + - Large JNLP + Large JNLP The IcedTea Project one-line @@ -24,7 +24,7 @@ decription of related-content - + @@ -43,4 +43,5 @@ arg1 arg2 - + + From ahughes at redhat.com Mon Apr 11 08:07:43 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 11 Apr 2011 16:07:43 +0100 Subject: /hg/icedtea-web: removed junit In-Reply-To: References: Message-ID: <20110411150743.GA13424@rivendell.middle-earth.co.uk> On 13:13 Mon 11 Apr , jvanek at icedtea.classpath.org wrote: > changeset 4f195bca0dc8 in /hg/icedtea-web > details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=4f195bca0dc8 > author: Jiri Vanek > date: Mon Apr 11 15:08:01 2011 +0200 > > removed junit > > What is this? I don't see any approval for such a change. I've now reverted it. The JUnit patch was discussed at length. You don't just go reverting such changes. IcedTea-Web is not your private plaything. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Mon Apr 11 08:44:41 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 11 Apr 2011 16:44:41 +0100 Subject: /hg/icedtea6: Fix missing clazz argument to all hotspot.jni.Call... In-Reply-To: References: Message-ID: <20110411154441.GB13424@rivendell.middle-earth.co.uk> On 20:58 Sun 10 Apr , mjw at icedtea.classpath.org wrote: > changeset ddd219edd416 in /hg/icedtea6 > details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=ddd219edd416 > author: Mark Wielaard > date: Sun Apr 10 22:51:11 2011 +0200 > > Fix missing clazz argument to all hotspot.jni.CallNonvirtual* stap > probes. > > 2011-04-10 Yasumasa Suenaga > > * tapset/hotspot_jni.stp.in (hotspot.jni.CallNonvirtual*): > Add missing clazz argument to all probes. Fix methodid to be > last argument. Add clazz to probestr. > Could we have this one in 7 too please? Cheers, -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Mon Apr 11 08:48:41 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 11 Apr 2011 16:48:41 +0100 Subject: [icedtea-web] RFC: Add additional lookup location for JUnit4 jar Message-ID: <20110411154841.GC13424@rivendell.middle-earth.co.uk> JUnit is installed in /usr/share/junit-4/lib/junit.jar on Gentoo systems. The attached patch adds this location to those searched for JUnit 4. Ok for HEAD? 2010-04-11 Andrew John Hughes * configure.ac: Check Gentoo install location for JUnit 4. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -------------- next part -------------- diff -r 934543b8084d configure.ac --- a/configure.ac Mon Apr 11 16:03:44 2011 +0100 +++ b/configure.ac Mon Apr 11 16:39:08 2011 +0100 @@ -86,7 +86,7 @@ IT_FIND_OPTIONAL_JAR([rhino], RHINO, [/usr/share/java/js.jar /usr/share/rhino-1.6/lib/js.jar]) IT_FIND_OPTIONAL_JAR([junit], JUNIT, - [/usr/share/java/junit4.jar]) + [/usr/share/java/junit4.jar /usr/share/junit-4/lib/junit.jar]) AC_CONFIG_FILES([jrunscript], [chmod u+x jrunscript]) AC_CONFIG_FILES([build.properties]) From jvanek at redhat.com Mon Apr 11 08:47:31 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 11 Apr 2011 17:47:31 +0200 Subject: removing junit as part of switching back to testng Message-ID: <4DA32293.2020502@redhat.com> diff -r 934543b8084d ChangeLog --- a/ChangeLog Mon Apr 11 16:03:44 2011 +0100 +++ b/ChangeLog Mon Apr 11 17:45:44 2011 +0200 @@ -1,3 +1,7 @@ +2011-04-11 Jiri Vanek + + * removed junit (1/2 from mooving to testNG) + 2011-04-08 Omair Majid * README: Update to add notes on rhino and junit. diff -r 934543b8084d Makefile.am --- a/Makefile.am Mon Apr 11 16:03:44 2011 +0100 +++ b/Makefile.am Mon Apr 11 17:45:44 2011 +0200 @@ -6,17 +6,6 @@ NETX_EXTRA_DIR=$(abs_top_srcdir)/extra/net/sourceforge/javaws/about/resources NETX_EXTRA_DIST_DIR=$(abs_top_builddir)/extra-lib/net/sourceforge/javaws/about/resources -TESTS_SRCDIR=$(abs_top_srcdir)/tests -TESTS_DIR=$(abs_top_builddir)/tests.build - -NETX_UNIT_TEST_SRCDIR=$(TESTS_SRCDIR)/netx/unit -NETX_UNIT_TEST_DIR=$(TESTS_DIR)/netx/unit - -JUNIT_RUNNER_DIR=$(TESTS_DIR)/junit-runner -JUNIT_RUNNER_SRCDIR=$(TESTS_SRCDIR)/junit-runner - -JUNIT_RUNNER_JAR=$(abs_top_builddir)/junit-runner.jar - # Build directories BOOT_DIR = $(abs_top_builddir)/bootstrap/jdk1.6.0 @@ -91,19 +80,6 @@ endif endif -if WITH_RHINO - RHINO_TESTS=check-pac-functions -else - RHINO_TESTS= -endif - -if WITH_JUNIT - JUNIT_TESTS=run-netx-unit-tests -else - JUNIT_TESTS= -endif - - PLUGIN_VERSION = IcedTea-Web $(FULL_VERSION) EXTRA_DIST = $(top_srcdir)/netx $(top_srcdir)/plugin javaws.png javaws.desktop.in extra launcher \ @@ -124,7 +100,7 @@ all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/javaws \ javaws.desktop stamps/docs.stamp launcher.build/itweb-settings itweb-settings.desktop -check-local: $(RHINO_TESTS) $(JUNIT_TESTS) +check-local: check-pac-functions clean-local: clean-netx clean-plugin clean-liveconnect clean-extra clean-bootstrap-directory \ clean-native-ecj clean-launchers clean-desktop-files clean-docs clean-tests @@ -134,8 +110,7 @@ .PHONY: clean-IcedTeaPlugin clean-add-netx clean-add-netx-debug clean-add-plugin clean-add-plugin-debug \ clean-bootstrap-directory clean-native-ecj clean-desktop-files clean-netx-docs clean-docs clean-plugin-docs \ - clean-tests check-local clean-launchers check-pac-functions run-netx-unit-tests clean-netx-tests \ - clean-junit-runner clean-netx-unit-tests + clean-tests check-local clean-launchers install-exec-local: ${mkinstalldirs} $(DESTDIR)$(bindir) $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/ $(DESTDIR)$(libdir) @@ -423,67 +398,11 @@ # check # ========================== -clean-tests: clean-netx-tests - if [ -e $(TESTS_DIR) ]; then \ - rmdir $(TESTS_DIR) ; \ - fi - check-pac-functions: stamps/bootstrap-directory.stamp ./jrunscript $(abs_top_srcdir)/tests/netx/pac/pac-funcs-test.js \ $$(readlink -f $(abs_top_srcdir)/netx/net/sourceforge/jnlp/runtime/pac-funcs.js) -junit-runner-source-files.txt: - find $(JUNIT_RUNNER_SRCDIR) -name '*.java' | sort > $@ - -$(JUNIT_RUNNER_JAR): junit-runner-source-files.txt - mkdir -p $(JUNIT_RUNNER_DIR) && \ - $(BOOT_DIR)/bin/javac $(IT_JAVACFLAGS) \ - -d $(JUNIT_RUNNER_DIR) \ - -classpath $(JUNIT_JAR) \ - @junit-runner-source-files.txt && \ - $(BOOT_DIR)/bin/jar cf $@ -C $(JUNIT_RUNNER_DIR) . - -netx-unit-tests-source-files.txt: - find $(NETX_UNIT_TEST_SRCDIR) -name '*.java' | sort > $@ - -stamps/netx-unit-tests-compile.stamp: stamps/netx.stamp \ - netx-unit-tests-source-files.txt - mkdir -p $(NETX_UNIT_TEST_DIR) && \ - $(BOOT_DIR)/bin/javac $(IT_JAVACFLAGS) \ - -d $(NETX_UNIT_TEST_DIR) \ - -classpath $(JUNIT_JAR):$(NETX_DIR)/lib/classes.jar \ - @netx-unit-tests-source-files.txt && \ - mkdir -p stamps && \ - touch $@ - -run-netx-unit-tests: stamps/netx-unit-tests-compile.stamp \ - $(JUNIT_RUNNER_JAR) - cp {$(NETX_UNIT_TEST_SRCDIR),$(NETX_UNIT_TEST_DIR)}/net/sourceforge/jnlp/basic.jnlp - cd $(NETX_UNIT_TEST_DIR) ; \ - class_names= ; \ - for test in `find -type f` ; do \ - class_name=`echo $$test | sed -e 's|\.class$$||' -e 's|^\./||'` ; \ - class_name=`echo $$class_name | sed -e 's|/|.|g' ` ; \ - class_names="$$class_names $$class_name" ; \ - done ; \ - echo $$class_names ; \ - CLASSPATH=$(NETX_DIR)/lib/classes.jar:$(JUNIT_JAR):$(JUNIT_RUNNER_JAR):. \ - $(BOOT_DIR)/bin/java -Xbootclasspath:$(RUNTIME) CommandLine $$class_names - -clean-netx-tests: clean-netx-unit-tests clean-junit-runner - if [ -e $(TESTS_DIR)/netx ]; then \ - rmdir $(TESTS_DIR)/netx ; \ - fi - -clean-junit-runner: - rm -f junit-runner-source-files.txt - rm -rf $(JUNIT_RUNNER_DIR) - rm -f $(JUNIT_RUNNER_JAR) - -clean-netx-unit-tests: - rm -f netx-unit-tests-source-files.txt - rm -rf $(NETX_UNIT_TEST_DIR) - rm -f stamps/netx-unit-tests-compile.stamp +-clean-tests: # plugin tests diff -r 934543b8084d configure.ac --- a/configure.ac Mon Apr 11 16:03:44 2011 +0100 +++ b/configure.ac Mon Apr 11 17:45:44 2011 +0200 @@ -85,8 +85,6 @@ IT_FIND_OPTIONAL_JAR([rhino], RHINO, [/usr/share/java/js.jar /usr/share/rhino-1.6/lib/js.jar]) -IT_FIND_OPTIONAL_JAR([junit], JUNIT, - [/usr/share/java/junit4.jar]) AC_CONFIG_FILES([jrunscript], [chmod u+x jrunscript]) AC_CONFIG_FILES([build.properties]) diff -r 934543b8084d tests/netx/unit/net/sourceforge/jnlp/ParserBasic.java --- a/tests/netx/unit/net/sourceforge/jnlp/ParserBasic.java Mon Apr 11 16:03:44 2011 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,282 +0,0 @@ -/* ParserBasic.java - Copyright (C) 2011 Red Hat, Inc. - -This file is part of IcedTea. - -IcedTea is free software; you can redistribute it and/or -modify it under the terms of the GNU General Public License as published by -the Free Software Foundation, version 2. - -IcedTea is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with IcedTea; see the file COPYING. If not, write to -the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301 USA. - -Linking this library statically or dynamically with other modules is -making a combined work based on this library. Thus, the terms and -conditions of the GNU General Public License cover the whole -combination. - -As a special exception, the copyright holders of this library give you -permission to link this library with independent modules to produce an -executable, regardless of the license terms of these independent -modules, and to copy and distribute the resulting executable under -terms of your choice, provided that you also meet, for each linked -independent module, the terms and conditions of the license of that -module. An independent module is a module which is not derived from -or based on this library. If you modify this library, you may extend -this exception to your version of the library, but you are not -obligated to do so. If you do not wish to do so, delete this -exception statement from your version. -*/ - -package net.sourceforge.jnlp; - -import java.io.ByteArrayInputStream; -import java.io.InputStream; -import java.util.List; - -import org.junit.After; -import org.junit.Assert; -import org.junit.Before; -import org.junit.BeforeClass; -import org.junit.Test; - -/** Test that the parser works with basic jnlp files */ -public class ParserBasic { - - private static Node root; - private static Parser parser; - - @BeforeClass - public static void setUp() throws ParseException { - ClassLoader cl = ParserBasic.class.getClassLoader(); - if (cl == null) { - cl = ClassLoader.getSystemClassLoader(); - } - InputStream jnlpStream = cl.getResourceAsStream("net/sourceforge/jnlp/basic.jnlp"); - root = Parser.getRootNode(jnlpStream); - parser = new Parser(null, null, root, false, false); - } - - @Test - public void testJNLP() { - Assert.assertEquals("1.0", parser.getSpecVersion().toString()); - Assert.assertEquals("http://localhost/", parser.getCodeBase().toString()); - Assert.assertEquals("http://localhost/jnlp.jnlp", parser.getFileLocation().toString()); - } - - @Test - public void testInformation() throws ParseException { - List infos = parser.getInfo(root); - Assert.assertNotNull(infos); - Assert.assertEquals(1, infos.size()); - InformationDesc info = infos.get(0); - Assert.assertNotNull(info); - } - - @Test - public void testInformationTitle() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - Assert.assertEquals("Large JNLP", info.getTitle()); - } - - @Test - public void testInformationVendor() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - Assert.assertEquals("The IcedTea Project", info.getVendor()); - } - - @Test - public void testInformationHomePage() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - Assert.assertEquals("http://homepage/", info.getHomepage().toString()); - } - - @Test - public void testInformationDescription() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - Assert.assertEquals("one-line", info.getDescription("one-line")); - Assert.assertEquals("short", info.getDescription("short")); - Assert.assertEquals("tooltip", info.getDescription("tooltip")); - } - - @Test - public void testInformationOfflineAllowed() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - Assert.assertEquals(true, info.isOfflineAllowed()); - - } - - @Test - public void testInformationIcon() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - - IconDesc[] icons = info.getIcons(IconDesc.DEFAULT); - Assert.assertNotNull(icons); - Assert.assertEquals(1, icons.length); - IconDesc icon = icons[0]; - Assert.assertNotNull(icon); - Assert.assertEquals("http://localhost/icon.png", icon.getLocation().toString()); - icons = info.getIcons(IconDesc.SPLASH); - Assert.assertNotNull(icons); - Assert.assertEquals(1, icons.length); - icon = icons[0]; - Assert.assertNotNull(icon); - Assert.assertEquals("http://localhost/splash.png", icon.getLocation().toString()); - - } - - @Test - public void testInformationShortcut() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - - ShortcutDesc shortcut = info.getShortcut(); - Assert.assertNotNull(shortcut); - Assert.assertTrue(shortcut.isOnline()); - Assert.assertTrue(shortcut.onDesktop()); - MenuDesc menu = shortcut.getMenu(); - Assert.assertNotNull(menu); - Assert.assertEquals("submenu", menu.getSubMenu()); - } - - @Test - public void testInformationAssociation() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - AssociationDesc[] associations = info.getAssociations(); - Assert.assertNotNull(associations); - Assert.assertEquals(1, associations.length); - AssociationDesc association = associations[0]; - Assert.assertNotNull(association); - String[] extensions = association.getExtensions(); - Assert.assertNotNull(extensions); - Assert.assertEquals(1, extensions.length); - String extension = extensions[0]; - Assert.assertNotNull(extension); - Assert.assertEquals("*.foo", extension); - String mimeType = association.getMimeType(); - Assert.assertNotNull(mimeType); - Assert.assertEquals("foo/bar", mimeType); - } - - @Test - public void testInformationRelatedContent() throws ParseException { - InformationDesc info = parser.getInfo(root).get(0); - - RelatedContentDesc[] relatedContents = info.getRelatedContents(); - Assert.assertNotNull(relatedContents); - Assert.assertEquals(1, relatedContents.length); - RelatedContentDesc relatedContent = relatedContents[0]; - Assert.assertNotNull(relatedContent); - Assert.assertEquals("related-content title", relatedContent.getTitle()); - Assert.assertNotNull(relatedContent.getLocation()); - Assert.assertEquals("http://related-content/", relatedContent.getLocation().toString()); - Assert.assertEquals("decription of related-content", relatedContent.getDescription()); - IconDesc relatedIcon = relatedContent.getIcon(); - Assert.assertNotNull(relatedIcon.getLocation()); - Assert.assertEquals("http://localhost/related-content-icon.png", relatedIcon.getLocation().toString()); - - } - - @Test - public void testSecurity() throws ParseException { - SecurityDesc security = parser.getSecurity(root); - Assert.assertNotNull(security); - Assert.assertEquals(SecurityDesc.ALL_PERMISSIONS, security.getSecurityType()); - } - - @Test - public void testResources() throws ParseException { - List allResources = parser.getResources(root, false); - Assert.assertNotNull(allResources); - Assert.assertEquals(1, allResources.size()); - ResourcesDesc resources = allResources.get(0); - Assert.assertNotNull(resources); - } - - @Test - public void testResourcesJava() throws ParseException { - ResourcesDesc resources = parser.getResources(root, false).get(0); - JREDesc[] jres = resources.getJREs(); - Assert.assertNotNull(jres); - Assert.assertEquals(1, jres.length); - JREDesc jre = jres[0]; - Assert.assertNotNull(jre); - Assert.assertEquals("1.3+", jre.getVersion().toString()); - Assert.assertEquals("http://java-url/", jre.getLocation().toString()); - Assert.assertEquals("64m", jre.getInitialHeapSize()); - Assert.assertEquals("128m", jre.getMaximumHeapSize()); - } - - @Test - public void testResourcesJar() throws ParseException { - ResourcesDesc resources = parser.getResources(root, false).get(0); - - boolean foundNative = false; - boolean foundEager = false; - boolean foundLazy = false; - - JARDesc[] jars = resources.getJARs(); - Assert.assertEquals(3, jars.length); - for (int i = 0; i < jars.length; i++) { - if (jars[i].isNative()) { - foundNative = true; - Assert.assertEquals("http://localhost/native.jar", jars[i].getLocation().toString()); - } else if (jars[i].isEager()) { - foundEager = true; - Assert.assertEquals("http://localhost/eager.jar", jars[i].getLocation().toString()); - } else if (jars[i].isLazy()) { - foundLazy = true; - Assert.assertEquals("http://localhost/lazy.jar", jars[i].getLocation().toString()); - } else { - Assert.assertFalse(true); - } - } - - Assert.assertTrue(foundNative); - Assert.assertTrue(foundLazy); - Assert.assertTrue(foundEager); - } - - @Test - public void testResourcesExtensions() throws ParseException { - ResourcesDesc resources = parser.getResources(root, false).get(0); - - ExtensionDesc[] extensions = resources.getExtensions(); - Assert.assertNotNull(extensions); - Assert.assertEquals(1, extensions.length); - ExtensionDesc extension = extensions[0]; - Assert.assertNotNull(extension); - Assert.assertEquals("http://extension/", extension.getLocation().toString()); - Assert.assertEquals("extension", extension.getName()); - Assert.assertEquals("0.1.1", extension.getVersion().toString()); - } - - @Test - public void testResourcesProperty() throws ParseException { - ResourcesDesc resources = parser.getResources(root, false).get(0); - - PropertyDesc[] properties = resources.getProperties(); - Assert.assertNotNull(properties); - Assert.assertEquals(1, properties.length); - - PropertyDesc property = properties[0]; - Assert.assertNotNull(property); - Assert.assertEquals("key", property.getKey()); - Assert.assertEquals("value", property.getValue()); - } - - @Test - public void testApplication() throws ParseException { - ApplicationDesc app = (ApplicationDesc) parser.getLauncher(root); - Assert.assertNotNull(app); - Assert.assertEquals("MainClass", app.getMainClass()); - Assert.assertArrayEquals(new String[] { "arg1", "arg2" }, app.getArguments()); - } - -} diff -r 934543b8084d tests/netx/unit/net/sourceforge/jnlp/ParserCornerCases.java --- a/tests/netx/unit/net/sourceforge/jnlp/ParserCornerCases.java Mon Apr 11 16:03:44 2011 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,91 +0,0 @@ -/* ParserCornerCases.java - Copyright (C) 2011 Red Hat, Inc. - -This file is part of IcedTea. - -IcedTea is free software; you can redistribute it and/or -modify it under the terms of the GNU General Public License as published by -the Free Software Foundation, version 2. - -IcedTea is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with IcedTea; see the file COPYING. If not, write to -the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301 USA. - -Linking this library statically or dynamically with other modules is -making a combined work based on this library. Thus, the terms and -conditions of the GNU General Public License cover the whole -combination. - -As a special exception, the copyright holders of this library give you -permission to link this library with independent modules to produce an -executable, regardless of the license terms of these independent -modules, and to copy and distribute the resulting executable under -terms of your choice, provided that you also meet, for each linked -independent module, the terms and conditions of the license of that -module. An independent module is a module which is not derived from -or based on this library. If you modify this library, you may extend -this exception to your version of the library, but you are not -obligated to do so. If you do not wish to do so, delete this -exception statement from your version. -*/ - -package net.sourceforge.jnlp; - -import java.io.ByteArrayInputStream; - -import org.junit.After; -import org.junit.Assert; -import org.junit.Before; -import org.junit.Test; - -/** Test various corner cases of the parser */ -public class ParserCornerCases { - @Test - public void testUnsupportedSpecNumber() throws ParseException { - String malformedJnlp = ""; - Node root = Parser.getRootNode(new ByteArrayInputStream(malformedJnlp.getBytes())); - Parser parser = new Parser(null, null, root, false, false); - Assert.assertEquals("11.11", parser.getSpecVersion().toString()); - } - - @Test - public void testApplicationAndComponent() throws ParseException { - String malformedJnlp = ""; - Node root = Parser.getRootNode(new ByteArrayInputStream(malformedJnlp.getBytes())); - Parser parser = new Parser(null, null, root, false, false); - Assert.assertNotNull(parser.getLauncher(root)); - } - - @Test - public void testCommentInElements() throws ParseException { - String malformedJnlp = "> "; - Node root = Parser.getRootNode(new ByteArrayInputStream(malformedJnlp.getBytes())); - Parser p = new Parser(null, null, root, false, false); - Assert.assertEquals("1.0", p.getSpecVersion().toString()); - } - - @Test - public void testCommentInAttributes() throws ParseException { - String malformedJnlp = ""; - Node root = Parser.getRootNode(new ByteArrayInputStream(malformedJnlp.getBytes())); - Parser p = new Parser(null, null, root, false, false); - Assert.assertEquals("", p.getSpecVersion().toString()); - } - - @Test - public void testNestedComments() throws ParseException { - String malformedJnlp = "" + - "" + - " -->" + - ""; - Node root = Parser.getRootNode(new ByteArrayInputStream(malformedJnlp.getBytes())); - Parser p = new Parser(null, null, root, false, false); - Assert.assertEquals(" -->", p.getInfo(root).get(0).getDescription()); - } -} diff -r 934543b8084d tests/netx/unit/net/sourceforge/jnlp/ParserMalformedXml.java --- a/tests/netx/unit/net/sourceforge/jnlp/ParserMalformedXml.java Mon Apr 11 16:03:44 2011 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,94 +0,0 @@ -/* ParserMalformedXml.java - Copyright (C) 2011 Red Hat, Inc. - -This file is part of IcedTea. - -IcedTea is free software; you can redistribute it and/or -modify it under the terms of the GNU General Public License as published by -the Free Software Foundation, version 2. - -IcedTea is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -General Public License for more details. - -You should have received a copy of the GNU General Public License -along with IcedTea; see the file COPYING. If not, write to -the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA -02110-1301 USA. - -Linking this library statically or dynamically with other modules is -making a combined work based on this library. Thus, the terms and -conditions of the GNU General Public License cover the whole -combination. - -As a special exception, the copyright holders of this library give you -permission to link this library with independent modules to produce an -executable, regardless of the license terms of these independent -modules, and to copy and distribute the resulting executable under -terms of your choice, provided that you also meet, for each linked -independent module, the terms and conditions of the license of that -module. An independent module is a module which is not derived from -or based on this library. If you modify this library, you may extend -this exception to your version of the library, but you are not -obligated to do so. If you do not wish to do so, delete this -exception statement from your version. -*/ - -package net.sourceforge.jnlp; - -import java.io.BufferedReader; -import java.io.ByteArrayInputStream; -import java.io.InputStream; -import java.io.InputStreamReader; -import java.io.IOException; - -import org.junit.BeforeClass; -import org.junit.Test; - -/** Test how well the parser deals with malformed xml */ -public class ParserMalformedXml { - - private static String originalJnlp = null; - - @BeforeClass - public static void setUp() throws IOException { - ClassLoader cl = ParserMalformedXml.class.getClassLoader(); - if (cl == null) { - cl = ClassLoader.getSystemClassLoader(); - } - InputStream is = cl.getResourceAsStream("net/sourceforge/jnlp/basic.jnlp"); - BufferedReader reader = new BufferedReader(new InputStreamReader(is)); - StringBuilder jnlpBuilder = new StringBuilder(); - String line; - while ( (line = reader.readLine()) != null) { - jnlpBuilder.append(line).append("\n"); - } - originalJnlp = jnlpBuilder.toString(); - } - - @Test - public void testMissingXmlDecleration() throws ParseException { - String malformedJnlp = originalJnlp.replaceFirst("<\\?xml.*\\?>", ""); - Parser.getRootNode(new ByteArrayInputStream(malformedJnlp.getBytes())); - } - - @Test - public void testMalformedArguments() throws ParseException { - String malformedJnlp = originalJnlp.replace("arg2", ""); - Parser.getRootNode(new ByteArrayInputStream(malformedJnlp.getBytes())); - } - - @Test - public void testUnquotedAttributes() throws ParseException { - String malformedJnlp = originalJnlp.replace("'jnlp.jnlp'", "jnlp.jnlp"); - Parser.getRootNode(new ByteArrayInputStream(malformedJnlp.getBytes())); - } - -} diff -r 934543b8084d tests/netx/unit/net/sourceforge/jnlp/basic.jnlp --- a/tests/netx/unit/net/sourceforge/jnlp/basic.jnlp Mon Apr 11 16:03:44 2011 +0100 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,47 +0,0 @@ - - - - - - Large JNLP - The IcedTea Project - - one-line - short - tooltip - - - - - - - - - - related-content <!-- or something -->title - decription of related-content - - - - - - - - - - - - - - - - - arg1 - arg2 - - - From ahughes at redhat.com Mon Apr 11 09:03:34 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 11 Apr 2011 17:03:34 +0100 Subject: removing junit as part of switching back to testng In-Reply-To: <4DA32293.2020502@redhat.com> References: <4DA32293.2020502@redhat.com> Message-ID: <20110411160334.GD13424@rivendell.middle-earth.co.uk> On 17:47 Mon 11 Apr , Jiri Vanek wrote: > diff -r 934543b8084d ChangeLog > --- a/ChangeLog Mon Apr 11 16:03:44 2011 +0100 > +++ b/ChangeLog Mon Apr 11 17:45:44 2011 +0200 > @@ -1,3 +1,7 @@ > +2011-04-11 Jiri Vanek > + > + * removed junit (1/2 from mooving to testNG) > + > 2011-04-08 Omair Majid > > * README: Update to add notes on rhino and junit. Why would we want to remove a perfectly working solution? We've already discusssed this at length. Please read the previous discussion. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From jvanek at redhat.com Mon Apr 11 09:05:36 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 11 Apr 2011 18:05:36 +0200 Subject: /hg/icedtea-web: removed junit In-Reply-To: <20110411150743.GA13424@rivendell.middle-earth.co.uk> References: <20110411150743.GA13424@rivendell.middle-earth.co.uk> Message-ID: <4DA326D0.5010705@redhat.com> On 04/11/2011 05:07 PM, Dr Andrew John Hughes wrote: > On 13:13 Mon 11 Apr , jvanek at icedtea.classpath.org wrote: >> changeset 4f195bca0dc8 in /hg/icedtea-web >> details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=4f195bca0dc8 >> author: Jiri Vanek >> date: Mon Apr 11 15:08:01 2011 +0200 >> >> removed junit >> >> > > What is this? I don't see any approval for such a change. I've now reverted it. > > The JUnit patch was discussed at length. You don't just go reverting such changes. > IcedTea-Web is not your private plaything. Not even yours. And you are making decisions on your own and ignoring others opinions about this. From jvanek at redhat.com Mon Apr 11 09:10:15 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Mon, 11 Apr 2011 18:10:15 +0200 Subject: Fwd: Re: removing junit as part of switching back to testng Message-ID: <4DA327E7.6000207@redhat.com> -------- Original Message -------- Subject: Re: removing junit as part of switching back to testng Date: Mon, 11 Apr 2011 18:04:21 +0200 From: Jiri Vanek To: Dr Andrew John Hughes On 04/11/2011 06:03 PM, Dr Andrew John Hughes wrote: > On 17:47 Mon 11 Apr , Jiri Vanek wrote: >> diff -r 934543b8084d ChangeLog >> --- a/ChangeLog Mon Apr 11 16:03:44 2011 +0100 >> +++ b/ChangeLog Mon Apr 11 17:45:44 2011 +0200 >> @@ -1,3 +1,7 @@ >> +2011-04-11 Jiri Vanek >> + >> + * removed junit (1/2 from mooving to testNG) >> + >> 2011-04-08 Omair Majid >> >> * README: Update to add notes on rhino and junit. > > Why would we want to remove a perfectly working solution? > > We've already discusssed this at length. Please read the previous discussion. No you weren't discusing this "perfect" solution. You have just made choice. Me and Omair have discused TestNG. You swapped to junit. WHY????? We lost much more then we have got.Omair's testng patch was also 'perfectly working solution'. From asu at redhat.com Mon Apr 11 11:20:39 2011 From: asu at redhat.com (Andrew Su) Date: Mon, 11 Apr 2011 14:20:39 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1592863020.2018211.1302101540485.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1432594239.25238.1302546039633.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hi, I have applied your patch and did some adjustments such as using the hash of the url as file name instead of having a really long directory. Questions? Comments? Cheers, Andrew ----- Original Message ----- > Hi Andrew. > > I've been looking over this. Rather than saying what I > don't like, I committed your patch to a local repository > and changed whatever I didn't like. It's much easier to > express what changes I would like to see in Java than > in English ;-). I've attached the patch with my changes, > so in this e-mail I'll just give reasons for those changes. > > A lot of it is pretty minor things (like turning > "if (e) return false;" into "if (e)\n return false"). > Feel free to ignore those stylistic kind of changes. > > The other changes are: > Adding a "," between the time and the folder identifier > in the RecentlyUsed file. > > CacheLRUPolicy: enums are better for singletons. Also, if > we have a singleton it's not so good to have many static > fields because if ever we needed more than one instance > of that class, the synchronized access to the static data > structures would break. > > CacheLRUPolicy.updateEntry: the changes here save us a > "substring" call, and it's slightly easier to read. > > getSortedKeys is now called getLRUSortedEntries. This was > the biggest change and the reasons for it were: > 1) We already have enough map iterations of the form: > for key in keyset: value = map.getvalue(key) > We shouldn't add to these. Iterating over (key, value) > entries is better. > 2) It's better to return the entries in the order that > we want to use them, rather than iterating backwards. > 3) We want to sort by the last updated time, so it's a > good idea to turn the strings into longs first. Comparing > strings might be correct (for now), but it's only > correct by coincidence, and that should be avoided. > > Regards, > Denis. > > ----- Original Message ----- > > ----- Original Message ----- > > > On 04/04/2011 05:45 PM, Andrew Su wrote: > > > >>> I think this patch would be easier to review if you split it > > > >>> into > > > >>> two patches - one to fix problems with files being > > > >>> overwritten, > > > >>> and another to enforce cache sizes. > > > > I've removed the section which will ensure the cache limit. Will > > > > post > > > > that later. > > > > > > > > > > Thanks! > > > > > > > + /** > > > > + * This will return a File pointing to the location of cache > > > > item. > > > > + * @param urlPath Path of cache item within cache directory. > > > > + * @return File if we have searched before, null otherwise. > > > > + */ > > > > + private static File getCacheFileIfExist(File urlPath){ > > > > > > > > > Instead of nitpicking, I am going to ask you to post some > > > information > > > about the files added/modified. I missed this during the original > > > review > > > (I suppose that might be a code smell and we need to do some > > > refactoring), but now I see that this patch introduces and/or > > > modifies > > > a > > > number of files: RecentlyUsed, per cache-entry directory, and > > > possibly > > > more metadata. Could you please describe what the overall design > > > of > > > this > > > cache is? What data each file contains? And in what format? > > > > File: > > /RecentlyUsed > > Desc: > > Keep track of the most recently accessed file. It can work without > > this file if we traverse the directory for this information. > > Format: > > This file is kept to how a regular properties file works > > Key=Value > > The Key consist of time accessed followed by the folder number. > > Example: > > 13020173404=/4/http/www.example.come/example.jar > > In this case the 4 at the end is the cache directory. > > > > > > File: > > /////*.info > > Desc: > > These files contain information about the file in the directory. > > Such as file length(size), last-modified header from download, and > > whether this file should be deleted at shutdown. > > Format: > > Each line consist of a Key=Value pair to report the state of the > > item. > > > > > > The above mentioned files are the only ones that we change. > > > > Design: > > It works similarly to the old cache with the addition of LRU and > > separate per cache-entry directory. > > During the initialization of the resource stage > > (ResourceTracker.initializeResource()) Here we will try and grab > > the most recently downloaded version of the cache-entry. If this > > entry does not exist it will prepare a directory to store this > > item. Now, to prevent another instance of plugin/javaws from > > overwriting the file we lock the PropertiesFile associated with > > this entry. If this file does exist, but not up to date then we > > create a new directory to store the new file. The old entry is > > marked for deletion at shutdown. > > > > Onto the downloading stage. This only happens if we have found > > the entry to be outdated or does not exist (from above). In here > > we try to lock on the PropertiesFile, and block if it is either > > being requested, or already in downloading progress. It is okay > > to block here because if there is a download for this file in > > progress, we can't use it until it is completed anyways. > > > > Loading the jars... nothing changed here. > > > > JVM Shutdown. At this point we will remove all compressed > > downloads and the folders they extract to since the check for > > size difference will always be true, it will try to redownload > > anyways. This can save some space at the end of the day. > > After removing these entries, it will proceed to removing all > > folders not being tracked by RecentlyUsed. (To get rid of the > > currently cached items before patch). > > > > > > > > I would love it if the response consists of patch with a new class > > > per > > > file/directory introduced/modified/repurposed and each class > > > contains > > > (as comments) the purpose and format :D > > > > I've move the policy to it's own class. Where it will handle the > > > > I've refactored the managing of the LRU policy into its own class. > > However modifying info class will not be moved anywhere since that > > is already handled by CacheEntry. The directories being created > > didn't seem to fit to be its own class either, can not pass it > > onto other plugin/javaws instances without having to traverse > > the directories (I wanted to avoid that). > > > > Cheers, > > Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110411_cache_change.patch Type: text/x-patch Size: 24028 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110411/c5f3b1c9/20110411_cache_change.patch From mark at klomp.org Mon Apr 11 11:36:18 2011 From: mark at klomp.org (Mark Wielaard) Date: Mon, 11 Apr 2011 20:36:18 +0200 Subject: /hg/icedtea6: Fix missing clazz argument to all hotspot.jni.Call... In-Reply-To: <20110411154441.GB13424@rivendell.middle-earth.co.uk> References: <20110411154441.GB13424@rivendell.middle-earth.co.uk> Message-ID: <1302546978.7968.22.camel@springer.wildebeest.org> On Mon, 2011-04-11 at 16:44 +0100, Dr Andrew John Hughes wrote: > On 20:58 Sun 10 Apr , mjw at icedtea.classpath.org wrote: > > changeset ddd219edd416 in /hg/icedtea6 > > details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=ddd219edd416 > > author: Mark Wielaard > > date: Sun Apr 10 22:51:11 2011 +0200 > > > > Fix missing clazz argument to all hotspot.jni.CallNonvirtual* stap > > probes. > > > > 2011-04-10 Yasumasa Suenaga > > > > * tapset/hotspot_jni.stp.in (hotspot.jni.CallNonvirtual*): > > Add missing clazz argument to all probes. Fix methodid to be > > last argument. Add clazz to probestr. > > > > Could we have this one in 7 too please? yes, sure, it should be a trivial port. Please do if you happen to have a 7 branch around. Thanks, Mark From ahughes at redhat.com Mon Apr 11 11:52:35 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 11 Apr 2011 19:52:35 +0100 Subject: /hg/icedtea6: Fix missing clazz argument to all hotspot.jni.Call... In-Reply-To: <1302546978.7968.22.camel@springer.wildebeest.org> References: <20110411154441.GB13424@rivendell.middle-earth.co.uk> <1302546978.7968.22.camel@springer.wildebeest.org> Message-ID: <20110411185235.GB7262@rivendell.middle-earth.co.uk> On 20:36 Mon 11 Apr , Mark Wielaard wrote: > On Mon, 2011-04-11 at 16:44 +0100, Dr Andrew John Hughes wrote: > > On 20:58 Sun 10 Apr , mjw at icedtea.classpath.org wrote: > > > changeset ddd219edd416 in /hg/icedtea6 > > > details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=ddd219edd416 > > > author: Mark Wielaard > > > date: Sun Apr 10 22:51:11 2011 +0200 > > > > > > Fix missing clazz argument to all hotspot.jni.CallNonvirtual* stap > > > probes. > > > > > > 2011-04-10 Yasumasa Suenaga > > > > > > * tapset/hotspot_jni.stp.in (hotspot.jni.CallNonvirtual*): > > > Add missing clazz argument to all probes. Fix methodid to be > > > last argument. Add clazz to probestr. > > > > > > > Could we have this one in 7 too please? > > yes, sure, it should be a trivial port. > Please do if you happen to have a 7 branch around. > Well, yes I can do it when I have time, but I was hoping you'd be able to do it as you actually know what this patch is supposed to fix... > Thanks, > > Mark > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From mark at klomp.org Mon Apr 11 12:29:14 2011 From: mark at klomp.org (Mark Wielaard) Date: Mon, 11 Apr 2011 21:29:14 +0200 Subject: /hg/icedtea6: Fix missing clazz argument to all hotspot.jni.Call... In-Reply-To: <20110411185235.GB7262@rivendell.middle-earth.co.uk> References: <20110411154441.GB13424@rivendell.middle-earth.co.uk> <1302546978.7968.22.camel@springer.wildebeest.org> <20110411185235.GB7262@rivendell.middle-earth.co.uk> Message-ID: <1302550154.7968.25.camel@springer.wildebeest.org> On Mon, 2011-04-11 at 19:52 +0100, Dr Andrew John Hughes wrote: > On 20:36 Mon 11 Apr , Mark Wielaard wrote: > > On Mon, 2011-04-11 at 16:44 +0100, Dr Andrew John Hughes wrote: > > > Could we have this one in 7 too please? > > > > yes, sure, it should be a trivial port. > > Please do if you happen to have a 7 branch around. > > > > Well, yes I can do it when I have time, but I was hoping you'd be able to do it > as you actually know what this patch is supposed to fix... :) Obviously my thoughts were the same, but about the 7 branch. Since I don't use that one daily, I am not very familiar with pushing patches to it. So if you don't have time, it might take me a while to try it there. I'll put it on my TODO list in case you don't beat me to it. Cheers, Mark From dbhole at redhat.com Mon Apr 11 13:12:09 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 11 Apr 2011 16:12:09 -0400 Subject: IcedTea-Web 1.1 branching on Wesnesday Message-ID: <20110411201208.GA6019@redhat.com> Hi, Significant development has been done on IcedTea-Web since 1.0 was branched and I think it is time to start thinking of 1.1. I was thinking of branching at end of Wesnesday (Apr. 13th) and then a release on the 26th after making sure things are stable. Once branched, no more features will be allowed in. Please let me know if you have any concerns about the above dates. Cheers, Deepak From Dmitry.Samersoff at oracle.com Sat Apr 9 01:25:53 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Sat, 09 Apr 2011 12:25:53 +0400 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> Message-ID: <4DA01811.5010906@oracle.com> Robert, I'm second with Andrew: > I really don't see why the current solution is such a problem. This > sounds like it's just going to make the output messy. because (1) we must not call external program during crash reporting (2) Information from /etc/*-releases doesn't reflect upgrades, especially if it's point upgrade of a particular package so we still need to collect libraries from client computer to open a core. So I would prefer to see: if exist [one of known to be useful /etc/*-releases ] : print distro name else: print "Unknown" -Dmitry On 2011-04-09 04:15, Dr Andrew John Hughes wrote: > It makes sense to include the distro-pkg-dev list on this discussion > rather than keeping it hidden away on this list that most distro > vendors won't be on. CCing it. > > On 4 April 2011 02:51, Robert Ottenhag wrote: >> >> I am about to improve the identification of popular Linux distros during dumping, see bug [1] and [2], that states that we should "correctly identify Ubuntu as the operating system in crash report instead of 'Debian'". >> >> >> >> I am somewhat reluctant to directly apply the suggested patch though which only adds to the existing problematic implementation where some distros not are identified at all, or are identified as a different distro. >> >> >> >> The current implementation [4] relies on the fact that most Linux distros have /etc/XXX-release files, where some distros have multiple files (see [3]). It then checks a fixed set of these files in order, and stops at the first matching file, so the order is important. >> >> >> >> (0) the current order is "/etc/mandrake-release", "/etc/sun-release", "/etc/redhat-release", "/etc/SuSE-release", "/etc/turbolinux-release", "/etc/gentoo-release", "/etc/debian_version", "/etc/ltib-release", "/etc/angstrom-version", and the proposed patch is to insert "/etc/lsb-release" right before "/etc/debian_version". >> >> >> >> If we instead of (0) replace it by (1) and (2) below it will be improved in many ways. >> >> >> >> (1) call the "lsb_release" tool, if it exists, which returns distro specific info based on either /etc/lsb_release or /etc/XXX-release, and that also knows which of multiple /etc/XXX-release files to check first, e.g. /etc/enterprise-linux before /etc/redhat-linux. >> > > This also won't work if the tool isn't installed. Most of the time, > it isn't. We found this when support was added to IcedTea to use its > content in the HotSpot crash dump and added it as a dependency in > distro packages as a result. > >> >> >> (2) list all /etc/*-release and /etc/*_version files, headed by the respective file names >> > > That would appear to create a lot of empty fields with no information. > >> >> >> The problem with (1) is that it calls an external process during a phase with might be very critical on resources, and it might not be available on specific old or embedded distros. Thus we still need (2) for which we need to verify that directory listing does not violate similar resource contraints. Regarding (2) the order of listed files should also be considered if it simplifies parsing of the dump output. >> >> >> >> The new solution would look something like >> >> OS: >> >> /etc/debian_version >> >> >> >> /etc/lsb-release >> >> >> >> >> >> Fundamentally, instead of having the JVM to try identify the Linux distro, it becomes up to the reader/parser of the dump output, but with the benefit of having all data available. >> > > I really don't see why the current solution is such a problem. This > sounds like it's just going to make the output messy. > >> >> >> References: >> >> >> >> [1] https://bugs.openjdk.java.net/show_bug.cgi?id=100137 >> >> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6986195 >> >> [3] http://linuxmafia.com/faq/Admin/release-files.html >> >> [4] hotspot/src/os/linux/vm/os_linux.cpp:os::print_os_info(). >> >> >> >> I appreciate any comments and ideas. >> >> >> >> Thanks >> >> >> >> /Robert >> >> >> >> -- >> >> Robert Ottenhag | Senior Member of Technical Staff >> Phone: +46850630961 | | Fax: +46850630911 | | Mobile: +46707106161 >> Oracle Oracle Java VM >> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm >> >> Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 >> >> Oracle is committed to developing practices and products that help protect the environment >> >> > > > -- > Andrew :-) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and the OpenJDK > http://www.gnu.org/software/classpath > http://openjdk.java.net > > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From jvanek at redhat.com Mon Apr 11 23:56:14 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 12 Apr 2011 08:56:14 +0200 Subject: removing junit as part of switching back to testng In-Reply-To: <20110411160334.GD13424@rivendell.middle-earth.co.uk> References: <4DA32293.2020502@redhat.com> <20110411160334.GD13424@rivendell.middle-earth.co.uk> Message-ID: <4DA3F78E.9060606@redhat.com> On 04/11/2011 06:03 PM, Dr Andrew John Hughes wrote: > On 17:47 Mon 11 Apr , Jiri Vanek wrote: >> diff -r 934543b8084d ChangeLog >> --- a/ChangeLog Mon Apr 11 16:03:44 2011 +0100 >> +++ b/ChangeLog Mon Apr 11 17:45:44 2011 +0200 >> @@ -1,3 +1,7 @@ >> +2011-04-11 Jiri Vanek >> + >> + * removed junit (1/2 from mooving to testNG) >> + >> 2011-04-08 Omair Majid >> >> * README: Update to add notes on rhino and junit. > > Why would we want to remove a perfectly working solution? > > We've already discusssed this at length. Please read the previous discussion. So I can consider that as approved? From ptisnovs at redhat.com Tue Apr 12 00:29:49 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Tue, 12 Apr 2011 09:29:49 +0200 Subject: PING: Reviewer needed - patch which fixes class SunToolkit for IcedTea6-1.8 and IcedTea6-1.9 Message-ID: <4DA3FF6D.3040101@redhat.com> -------- Original Message -------- Subject: Reviewer needed - patch which fixes class SunToolkit for IcedTea6-1.8 and IcedTea6-1.9 Date: Thu, 31 Mar 2011 13:55:23 +0200 From: Pavel Tisnovsky To: IcedTea Hi all, I addition to my previous mail, I'd also like to backport SunToolkit patch to IcedTea6-1.8 and IcedTea6-1.9. Diffs generated against recent IcedTea6-1.8 and IcedTea6-1.9 are stored in attachments. Please note, that the patch itself is a bit different from patch used in IcedTea6-1.10 and IcedTea6 HEAD due to different lines being patched. ChangeLog entry is the same: 2011-03-31 Pavel Tisnovsky * Makefile.am: Add new patch. * NEWS: Updated (added info about new fix). * patches/mark_sun_toolkit_privileged_code.patch: Patch which fixes the AccessControlException while working with Color class in a PropertyEditor Can anybody please review it? Cheers Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: hg_diff_6-1.8.patch Type: text/x-patch Size: 1779 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/10ccf66e/hg_diff_6-1.8.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: hg_diff_6-1.9.patch Type: text/x-patch Size: 1707 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/10ccf66e/hg_diff_6-1.9.patch From jvanek at redhat.com Tue Apr 12 00:50:39 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 12 Apr 2011 09:50:39 +0200 Subject: adding testng after removig of junit Message-ID: <4DA4044F.5010407@redhat.com> -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: removed-junit.patch Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/39381685/removed-junit.patch -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: addTestNg.patch Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/39381685/addTestNg.patch From ptisnovs at redhat.com Tue Apr 12 04:02:17 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Tue, 12 Apr 2011 13:02:17 +0200 Subject: adding testng after removig of junit In-Reply-To: <4DA4044F.5010407@redhat.com> References: <4DA4044F.5010407@redhat.com> Message-ID: <4DA43139.2080505@redhat.com> Hi all, as a person who is going to regularly run the IcedTea-web tests (I'd also like to add new test cases in the near future) I'd prefer if he really began to use TestNG. Cheers Pavel Jiri Vanek wrote: From xerxes at zafena.se Tue Apr 12 04:16:38 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 12 Apr 2011 13:16:38 +0200 Subject: RFC: PR698 Shark failes to find LLVM 2.9 System headers during build Message-ID: <4DA43496.5080409@zafena.se> In LLVM 2.9 llvm/System/Threading.h and llvm/System/Host.h have been moved to llvm/Support/Threading.h and llvm/Support/Host.h http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=689 The attached patches use SHARK_LLVM_VERSION to include Support/*.h for LLVM 2.9 and later and still includes System/*.h for older LLVM releases. Ok to commit all attached patches to: Icedtea6-1.9 ? Icedtea6-1.10 ? Icedtea6 trunk? Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-1.9-shark-llvm-2.9.patch Type: text/x-patch Size: 2882 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/5bd292b3/icedtea6-1.9-shark-llvm-2.9.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-1.10-shark-llvm-2.9.patch Type: text/x-patch Size: 2824 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/5bd292b3/icedtea6-1.10-shark-llvm-2.9.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-1.11-shark-llvm-2.9.patch Type: text/x-patch Size: 2858 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/5bd292b3/icedtea6-1.11-shark-llvm-2.9.patch From gbenson at redhat.com Tue Apr 12 05:20:31 2011 From: gbenson at redhat.com (Gary Benson) Date: Tue, 12 Apr 2011 13:20:31 +0100 Subject: RFC: PR698 Shark failes to find LLVM 2.9 System headers during build In-Reply-To: <4DA43496.5080409@zafena.se> References: <4DA43496.5080409@zafena.se> Message-ID: <20110412122031.GA2656@redhat.com> Hi Xerxes, The patches look good to me. Would you be able to submit them upstream too? I can walk you through the process if you like. Thanks, Gary Xerxes R?nby wrote: > In LLVM 2.9 > llvm/System/Threading.h and llvm/System/Host.h > have been moved to > llvm/Support/Threading.h and llvm/Support/Host.h > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=689 > > The attached patches use SHARK_LLVM_VERSION to include Support/*.h > for LLVM 2.9 and later and still includes System/*.h for older LLVM > releases. > > Ok to commit all attached patches to: > Icedtea6-1.9 ? > > Icedtea6-1.10 ? > > Icedtea6 trunk? > > > Cheers > Xerxes > > Index: icedtea6-1.9/Makefile.am > =================================================================== > --- icedtea6-1.9.orig/Makefile.am 2011-04-08 12:41:33.894716001 +0200 > +++ icedtea6-1.9/Makefile.am 2011-04-08 12:43:04.274716002 +0200 > @@ -340,7 +340,8 @@ > patches/latent_jaxp_bug.patch \ > patches/openjdk/6675802-securityExceptions-applets.patch \ > patches/openjdk/6691503-malicious-applet-always-on-top.patch \ > - patches/jtreg-LastErrorString.patch > + patches/jtreg-LastErrorString.patch \ > + patches/shark-llvm-2.9.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ > Index: icedtea6-1.9/patches/shark-llvm-2.9.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6-1.9/patches/shark-llvm-2.9.patch 2011-04-08 12:41:27.358716002 +0200 > @@ -0,0 +1,29 @@ > +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 > ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 > +@@ -43,7 +43,11 @@ > + #include > + #endif > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > ++#endif > + #include > + #include > + #include > +@@ -52,8 +56,12 @@ > + #include > + #include > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > + #endif > ++#endif > + > + #include > + > Index: icedtea6-1.9/NEWS > =================================================================== > --- icedtea6-1.9.orig/NEWS 2011-04-08 12:45:29.482716000 +0200 > +++ icedtea6-1.9/NEWS 2011-04-08 12:54:16.214716001 +0200 > @@ -16,6 +16,8 @@ > - S6980392, PR642: simple correction in testcase, added missing bracket > * Plugin > - PR542: Plugin fails with NPE on http://www.openprocessing.org/visuals/iframe.php?visualID=2615 > +* Shark > + - PR689: Shark failes to find LLVM 2.9 System headers during build > > New in release 1.9.7 (2011-02-15): > > Index: icedtea6-1.9/ChangeLog > =================================================================== > --- icedtea6-1.9.orig/ChangeLog 2011-04-08 12:54:43.482716002 +0200 > +++ icedtea6-1.9/ChangeLog 2011-04-08 12:57:45.726716001 +0200 > @@ -1,3 +1,11 @@ > +2011-04-08 Xerxes R??nby > + > + PR689: Shark failes to find LLVM 2.9 System headers during build > + * Makefile.am: Add patch. > + * patches/shark-llvm-2.9.patch: > + In LLVM 2.9 System headers are moved to Support. > + * NEWS: Updated. > + > 2010-11-01 Deepak Bhole > > PR542: Plugin fails with NPE on > Index: icedtea6-1.10/patches/shark-llvm-2.9.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6-1.10/patches/shark-llvm-2.9.patch 2011-04-08 13:00:48.446716001 +0200 > @@ -0,0 +1,29 @@ > +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 > ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 > +@@ -43,7 +43,11 @@ > + #include > + #endif > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > ++#endif > + #include > + #include > + #include > +@@ -52,8 +56,12 @@ > + #include > + #include > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > + #endif > ++#endif > + > + #include > + > Index: icedtea6-1.10/ChangeLog > =================================================================== > --- icedtea6-1.10.orig/ChangeLog 2011-04-08 12:37:14.000000000 +0200 > +++ icedtea6-1.10/ChangeLog 2011-04-08 13:01:40.018716003 +0200 > @@ -1,3 +1,11 @@ > +2011-04-08 Xerxes R??nby > + > + PR689: Shark failes to find LLVM 2.9 System headers during build > + * Makefile.am: Add patch. > + * patches/shark-llvm-2.9.patch: > + In LLVM 2.9 System headers are moved to Support. > + * NEWS: Updated. > + > 2011-04-04 Andrew John Hughes > > * NEWS: Add 1.10.2. > Index: icedtea6-1.10/NEWS > =================================================================== > --- icedtea6-1.10.orig/NEWS 2011-04-08 12:37:14.000000000 +0200 > +++ icedtea6-1.10/NEWS 2011-04-08 13:02:34.214716003 +0200 > @@ -11,6 +11,9 @@ > > New in release 1.10.2 (20XX-XX-XX): > > +* Shark > + - PR689: Shark failes to find LLVM 2.9 System headers during build. > + > New in release 1.10.1 (2011-04-04): > > * HotSpot 20 updated to b11. > Index: icedtea6-1.10/Makefile.am > =================================================================== > --- icedtea6-1.10.orig/Makefile.am 2011-04-08 12:37:14.000000000 +0200 > +++ icedtea6-1.10/Makefile.am 2011-04-08 13:03:39.558716000 +0200 > @@ -329,7 +329,8 @@ > patches/g356743-libpng-1.5.patch \ > patches/mark_sun_toolkit_privileged_code.patch \ > patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ > - patches/openjdk/7031385-gcc-register-allocation-fix.patch > + patches/openjdk/7031385-gcc-register-allocation-fix.patch \ > + patches/shark-llvm-2.9.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ > Index: icedtea6/patches/shark-llvm-2.9.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6/patches/shark-llvm-2.9.patch 2011-04-08 13:06:04.670716001 +0200 > @@ -0,0 +1,29 @@ > +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 > ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 > +@@ -43,7 +43,11 @@ > + #include > + #endif > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > ++#endif > + #include > + #include > + #include > +@@ -52,8 +56,12 @@ > + #include > + #include > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > + #endif > ++#endif > + > + #include > + > Index: icedtea6/ChangeLog > =================================================================== > --- icedtea6.orig/ChangeLog 2011-04-08 11:03:50.000000000 +0200 > +++ icedtea6/ChangeLog 2011-04-08 13:07:50.522716000 +0200 > @@ -1,3 +1,11 @@ > +2011-04-08 Xerxes R??nby > + > + PR689: Shark failes to find LLVM 2.9 System headers during build > + * Makefile.am: Add patch. > + * patches/shark-llvm-2.9.patch: > + In LLVM 2.9 System headers are moved to Support. > + * NEWS: Updated. > + > 2011-03-31 Deepak Bhole > > S7031385, PR680: Incorrect register allocation in > Index: icedtea6/NEWS > =================================================================== > --- icedtea6.orig/NEWS 2011-04-08 11:03:50.000000000 +0200 > +++ icedtea6/NEWS 2011-04-08 13:07:22.206716002 +0200 > @@ -46,6 +46,8 @@ > - On ARM, force interpreter to be built in ARM mode. > - MIPS: 64-bit and interpreter inlining by default. > - Trivial implementation of stubs for MIPS. > +* Shark > + - PR689: Shark failes to find LLVM 2.9 System headers during build. > > New in release 1.10 (2011-XX-XX): > > Index: icedtea6/Makefile.am > =================================================================== > --- icedtea6.orig/Makefile.am 2011-04-08 11:03:50.000000000 +0200 > +++ icedtea6/Makefile.am 2011-04-08 13:06:04.698716001 +0200 > @@ -335,7 +335,8 @@ > patches/g356743-libpng-1.5.patch \ > patches/revert-6885123.patch \ > patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ > - patches/openjdk/7031385-gcc-register-allocation-fix.patch > + patches/openjdk/7031385-gcc-register-allocation-fix.patch \ > + patches/shark-llvm-2.9.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ -- http://gbenson.net/ From ahughes at redhat.com Tue Apr 12 05:27:36 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 12 Apr 2011 13:27:36 +0100 Subject: RFC: PR698 Shark failes to find LLVM 2.9 System headers during build In-Reply-To: <4DA43496.5080409@zafena.se> References: <4DA43496.5080409@zafena.se> Message-ID: <20110412122736.GD7262@rivendell.middle-earth.co.uk> On 13:16 Tue 12 Apr , Xerxes R?nby wrote: > In LLVM 2.9 > llvm/System/Threading.h and llvm/System/Host.h > have been moved to > llvm/Support/Threading.h and llvm/Support/Host.h > > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=689 > > The attached patches use SHARK_LLVM_VERSION to include Support/*.h for LLVM 2.9 > and later and still includes System/*.h for older LLVM releases. > > Ok to commit all attached patches to: > Icedtea6-1.9 ? > > Icedtea6-1.10 ? > > Icedtea6 trunk? > There is a typo in NEWS: failes -> fails. I'm also getting question marks in your surname in the ChangeLog. Otherwise, the change looks good for all three branches. Why not 1.8 too? > > Cheers > Xerxes > Index: icedtea6-1.9/Makefile.am > =================================================================== > --- icedtea6-1.9.orig/Makefile.am 2011-04-08 12:41:33.894716001 +0200 > +++ icedtea6-1.9/Makefile.am 2011-04-08 12:43:04.274716002 +0200 > @@ -340,7 +340,8 @@ > patches/latent_jaxp_bug.patch \ > patches/openjdk/6675802-securityExceptions-applets.patch \ > patches/openjdk/6691503-malicious-applet-always-on-top.patch \ > - patches/jtreg-LastErrorString.patch > + patches/jtreg-LastErrorString.patch \ > + patches/shark-llvm-2.9.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ > Index: icedtea6-1.9/patches/shark-llvm-2.9.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6-1.9/patches/shark-llvm-2.9.patch 2011-04-08 12:41:27.358716002 +0200 > @@ -0,0 +1,29 @@ > +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 > ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 > +@@ -43,7 +43,11 @@ > + #include > + #endif > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > ++#endif > + #include > + #include > + #include > +@@ -52,8 +56,12 @@ > + #include > + #include > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > + #endif > ++#endif > + > + #include > + > Index: icedtea6-1.9/NEWS > =================================================================== > --- icedtea6-1.9.orig/NEWS 2011-04-08 12:45:29.482716000 +0200 > +++ icedtea6-1.9/NEWS 2011-04-08 12:54:16.214716001 +0200 > @@ -16,6 +16,8 @@ > - S6980392, PR642: simple correction in testcase, added missing bracket > * Plugin > - PR542: Plugin fails with NPE on http://www.openprocessing.org/visuals/iframe.php?visualID=2615 > +* Shark > + - PR689: Shark failes to find LLVM 2.9 System headers during build > > New in release 1.9.7 (2011-02-15): > > Index: icedtea6-1.9/ChangeLog > =================================================================== > --- icedtea6-1.9.orig/ChangeLog 2011-04-08 12:54:43.482716002 +0200 > +++ icedtea6-1.9/ChangeLog 2011-04-08 12:57:45.726716001 +0200 > @@ -1,3 +1,11 @@ > +2011-04-08 Xerxes R??nby > + > + PR689: Shark failes to find LLVM 2.9 System headers during build > + * Makefile.am: Add patch. > + * patches/shark-llvm-2.9.patch: > + In LLVM 2.9 System headers are moved to Support. > + * NEWS: Updated. > + > 2010-11-01 Deepak Bhole > > PR542: Plugin fails with NPE on > Index: icedtea6-1.10/patches/shark-llvm-2.9.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6-1.10/patches/shark-llvm-2.9.patch 2011-04-08 13:00:48.446716001 +0200 > @@ -0,0 +1,29 @@ > +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 > ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 > +@@ -43,7 +43,11 @@ > + #include > + #endif > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > ++#endif > + #include > + #include > + #include > +@@ -52,8 +56,12 @@ > + #include > + #include > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > + #endif > ++#endif > + > + #include > + > Index: icedtea6-1.10/ChangeLog > =================================================================== > --- icedtea6-1.10.orig/ChangeLog 2011-04-08 12:37:14.000000000 +0200 > +++ icedtea6-1.10/ChangeLog 2011-04-08 13:01:40.018716003 +0200 > @@ -1,3 +1,11 @@ > +2011-04-08 Xerxes R??nby > + > + PR689: Shark failes to find LLVM 2.9 System headers during build > + * Makefile.am: Add patch. > + * patches/shark-llvm-2.9.patch: > + In LLVM 2.9 System headers are moved to Support. > + * NEWS: Updated. > + > 2011-04-04 Andrew John Hughes > > * NEWS: Add 1.10.2. > Index: icedtea6-1.10/NEWS > =================================================================== > --- icedtea6-1.10.orig/NEWS 2011-04-08 12:37:14.000000000 +0200 > +++ icedtea6-1.10/NEWS 2011-04-08 13:02:34.214716003 +0200 > @@ -11,6 +11,9 @@ > > New in release 1.10.2 (20XX-XX-XX): > > +* Shark > + - PR689: Shark failes to find LLVM 2.9 System headers during build. > + > New in release 1.10.1 (2011-04-04): > > * HotSpot 20 updated to b11. > Index: icedtea6-1.10/Makefile.am > =================================================================== > --- icedtea6-1.10.orig/Makefile.am 2011-04-08 12:37:14.000000000 +0200 > +++ icedtea6-1.10/Makefile.am 2011-04-08 13:03:39.558716000 +0200 > @@ -329,7 +329,8 @@ > patches/g356743-libpng-1.5.patch \ > patches/mark_sun_toolkit_privileged_code.patch \ > patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ > - patches/openjdk/7031385-gcc-register-allocation-fix.patch > + patches/openjdk/7031385-gcc-register-allocation-fix.patch \ > + patches/shark-llvm-2.9.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ > Index: icedtea6/patches/shark-llvm-2.9.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6/patches/shark-llvm-2.9.patch 2011-04-08 13:06:04.670716001 +0200 > @@ -0,0 +1,29 @@ > +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 > ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 > +@@ -43,7 +43,11 @@ > + #include > + #endif > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > ++#endif > + #include > + #include > + #include > +@@ -52,8 +56,12 @@ > + #include > + #include > + #include > ++#if SHARK_LLVM_VERSION >= 29 > ++#include > ++#else > + #include > + #endif > ++#endif > + > + #include > + > Index: icedtea6/ChangeLog > =================================================================== > --- icedtea6.orig/ChangeLog 2011-04-08 11:03:50.000000000 +0200 > +++ icedtea6/ChangeLog 2011-04-08 13:07:50.522716000 +0200 > @@ -1,3 +1,11 @@ > +2011-04-08 Xerxes R??nby > + > + PR689: Shark failes to find LLVM 2.9 System headers during build > + * Makefile.am: Add patch. > + * patches/shark-llvm-2.9.patch: > + In LLVM 2.9 System headers are moved to Support. > + * NEWS: Updated. > + > 2011-03-31 Deepak Bhole > > S7031385, PR680: Incorrect register allocation in > Index: icedtea6/NEWS > =================================================================== > --- icedtea6.orig/NEWS 2011-04-08 11:03:50.000000000 +0200 > +++ icedtea6/NEWS 2011-04-08 13:07:22.206716002 +0200 > @@ -46,6 +46,8 @@ > - On ARM, force interpreter to be built in ARM mode. > - MIPS: 64-bit and interpreter inlining by default. > - Trivial implementation of stubs for MIPS. > +* Shark > + - PR689: Shark failes to find LLVM 2.9 System headers during build. > > New in release 1.10 (2011-XX-XX): > > Index: icedtea6/Makefile.am > =================================================================== > --- icedtea6.orig/Makefile.am 2011-04-08 11:03:50.000000000 +0200 > +++ icedtea6/Makefile.am 2011-04-08 13:06:04.698716001 +0200 > @@ -335,7 +335,8 @@ > patches/g356743-libpng-1.5.patch \ > patches/revert-6885123.patch \ > patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ > - patches/openjdk/7031385-gcc-register-allocation-fix.patch > + patches/openjdk/7031385-gcc-register-allocation-fix.patch \ > + patches/shark-llvm-2.9.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Apr 12 05:30:31 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 12 Apr 2011 13:30:31 +0100 Subject: PING: Reviewer needed - patch which fixes class SunToolkit for IcedTea6-1.8 and IcedTea6-1.9 In-Reply-To: <4DA3FF6D.3040101@redhat.com> References: <4DA3FF6D.3040101@redhat.com> Message-ID: <20110412123031.GE7262@rivendell.middle-earth.co.uk> On 09:29 Tue 12 Apr , Pavel Tisnovsky wrote: > > > -------- Original Message -------- > Subject: Reviewer needed - patch which fixes class SunToolkit for > IcedTea6-1.8 and IcedTea6-1.9 > Date: Thu, 31 Mar 2011 13:55:23 +0200 > From: Pavel Tisnovsky > To: IcedTea > > Hi all, > > I addition to my previous mail, I'd also like to backport SunToolkit > patch to IcedTea6-1.8 and IcedTea6-1.9. Diffs generated against recent > IcedTea6-1.8 and IcedTea6-1.9 are stored in attachments. > > Please note, that the patch itself is a bit different from patch used in > IcedTea6-1.10 and IcedTea6 HEAD due to different lines being patched. > That's why it's a good idea to post the specific patch being applied as there will be changes when backporting. Here, there is a mistake; the NEWS item is being wrongly filed under Plugin in both patches. It should be placed under 'Backports' as in HEAD and 1.10. > ChangeLog entry is the same: > 2011-03-31 Pavel Tisnovsky > > * Makefile.am: Add new patch. > * NEWS: Updated (added info about new fix). > * patches/mark_sun_toolkit_privileged_code.patch: > Patch which fixes the AccessControlException while > working with Color class in a PropertyEditor > > > Can anybody please review it? > > Cheers > Pavel > > diff -r c4b749a83103 Makefile.am > --- a/Makefile.am Fri Mar 25 15:36:46 2011 -0400 > +++ b/Makefile.am Thu Mar 31 13:25:26 2011 +0200 > @@ -377,7 +377,8 @@ > patches/latent_jaxp_bug.patch \ > patches/openjdk/6675802-securityExceptions-applets.patch \ > patches/openjdk/6691503-malicious-applet-always-on-top.patch \ > - patches/jtreg-LastErrorString.patch > + patches/jtreg-LastErrorString.patch \ > + patches/mark_sun_toolkit_privileged_code.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += patches/hotspot/$(HSBUILD)/openjdk-6886353-ignore_deoptimizealot.patch \ > diff -r c4b749a83103 NEWS > --- a/NEWS Fri Mar 25 15:36:46 2011 -0400 > +++ b/NEWS Thu Mar 31 13:25:26 2011 +0200 > @@ -16,6 +16,7 @@ > - PR632: patches/security/20110215/6878713.patch breaks shark zero build > * Plugin > - PR542: Plugin fails with NPE on http://www.openprocessing.org/visuals/iframe.php?visualID=2615 > + - Fixed AccessControlContext which was thrown while working with Color class in a PropertyEditor > > New in release 1.8.7 (2011-02-15): > > diff -r c4b749a83103 patches/mark_sun_toolkit_privileged_code.patch > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/patches/mark_sun_toolkit_privileged_code.patch Thu Mar 31 13:25:26 2011 +0200 > @@ -0,0 +1,12 @@ > +--- openjdk/jdk/src/share/classes/sun/awt/SunToolkit.orig.java 2011-03-11 10:48:29.000000000 +0100 > ++++ openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java 2011-03-11 11:24:33.000000000 +0100 > +@@ -70,8 +70,7 @@ > + > + /* Load debug settings for native code */ > + static { > +- String nativeDebug = System.getProperty("sun.awt.nativedebug"); > +- if ("true".equalsIgnoreCase(nativeDebug)) { > ++ if (AccessController.doPrivileged(new GetBooleanAction("sun.awt.nativedebug"))) { > + DebugSettings.init(); > + } > + }; > > diff -r e4336b504f8a Makefile.am > --- a/Makefile.am Fri Mar 25 15:04:00 2011 -0400 > +++ b/Makefile.am Thu Mar 31 13:26:40 2011 +0200 > @@ -340,7 +340,8 @@ > patches/latent_jaxp_bug.patch \ > patches/openjdk/6675802-securityExceptions-applets.patch \ > patches/openjdk/6691503-malicious-applet-always-on-top.patch \ > - patches/jtreg-LastErrorString.patch > + patches/jtreg-LastErrorString.patch \ > + patches/mark_sun_toolkit_privileged_code.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ > diff -r e4336b504f8a NEWS > --- a/NEWS Fri Mar 25 15:04:00 2011 -0400 > +++ b/NEWS Thu Mar 31 13:26:40 2011 +0200 > @@ -16,6 +16,7 @@ > - S6980392, PR642: simple correction in testcase, added missing bracket > * Plugin > - PR542: Plugin fails with NPE on http://www.openprocessing.org/visuals/iframe.php?visualID=2615 > + - Fixed AccessControlContext which was thrown while working with Color class in a PropertyEditor > > New in release 1.9.7 (2011-02-15): > > diff -r e4336b504f8a patches/mark_sun_toolkit_privileged_code.patch > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/patches/mark_sun_toolkit_privileged_code.patch Thu Mar 31 13:26:40 2011 +0200 > @@ -0,0 +1,12 @@ > +--- openjdk/jdk/src/share/classes/sun/awt/SunToolkit.orig.java 2011-03-11 10:48:29.000000000 +0100 > ++++ openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java 2011-03-11 11:24:33.000000000 +0100 > +@@ -70,8 +70,7 @@ > + > + /* Load debug settings for native code */ > + static { > +- String nativeDebug = System.getProperty("sun.awt.nativedebug"); > +- if ("true".equalsIgnoreCase(nativeDebug)) { > ++ if (AccessController.doPrivileged(new GetBooleanAction("sun.awt.nativedebug"))) { > + DebugSettings.init(); > + } > + }; > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Apr 12 05:33:08 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 12 Apr 2011 13:33:08 +0100 Subject: adding testng after removig of junit In-Reply-To: <4DA43139.2080505@redhat.com> References: <4DA4044F.5010407@redhat.com> <4DA43139.2080505@redhat.com> Message-ID: <20110412123308.GF7262@rivendell.middle-earth.co.uk> On 13:02 Tue 12 Apr , Pavel Tisnovsky wrote: > Hi all, > > as a person who is going to regularly run the IcedTea-web tests (I'd > also like to add new test cases in the near future) I'd prefer if he > really began to use TestNG. > Why? (BTW, I think you want 'it' not 'he' if I'm reading the above correctly and you're referring to IcedTea-Web) > Cheers > Pavel > > > > Jiri Vanek wrote: -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From jvanek at redhat.com Tue Apr 12 05:43:06 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 12 Apr 2011 14:43:06 +0200 Subject: adding testng after removig of junit In-Reply-To: <20110412123308.GF7262@rivendell.middle-earth.co.uk> References: <4DA4044F.5010407@redhat.com> <4DA43139.2080505@redhat.com> <20110412123308.GF7262@rivendell.middle-earth.co.uk> Message-ID: <4DA448DA.4030803@redhat.com> On 04/12/2011 02:33 PM, Dr Andrew John Hughes wrote: > On 13:02 Tue 12 Apr , Pavel Tisnovsky wrote: >> Hi all, >> >> as a person who is going to regularly run the IcedTea-web tests (I'd >> also like to add new test cases in the near future) I'd prefer if he >> really began to use TestNG. >> > > Why? > > (BTW, I think you want 'it' not 'he' if I'm reading the above correctly > and you're referring to IcedTea-Web) > >> Cheers >> Pavel >> >> >> Why? It is simple. And I wrote it many times - testng have much better output then junit. So it is with configuration. Why are you ignoring my posts?! Why have you not defend YOUR solution? I posted reasons to switch to testng. You make me no reply except ignoring me. J. From ahughes at redhat.com Tue Apr 12 06:01:40 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 12 Apr 2011 14:01:40 +0100 Subject: adding testng after removig of junit In-Reply-To: <4DA448DA.4030803@redhat.com> References: <4DA4044F.5010407@redhat.com> <4DA43139.2080505@redhat.com> <20110412123308.GF7262@rivendell.middle-earth.co.uk> <4DA448DA.4030803@redhat.com> Message-ID: <20110412130140.GH7262@rivendell.middle-earth.co.uk> On 14:43 Tue 12 Apr , Jiri Vanek wrote: > On 04/12/2011 02:33 PM, Dr Andrew John Hughes wrote: > > On 13:02 Tue 12 Apr , Pavel Tisnovsky wrote: > >> Hi all, > >> > >> as a person who is going to regularly run the IcedTea-web tests (I'd > >> also like to add new test cases in the near future) I'd prefer if he > >> really began to use TestNG. > >> > > > > Why? > > > > (BTW, I think you want 'it' not 'he' if I'm reading the above correctly > > and you're referring to IcedTea-Web) > > > >> Cheers > >> Pavel > >> > >> > >> > > Why? It is simple. And I wrote it many times - testng have much better > output then junit. So it is with configuration. Why are you ignoring my > posts?! Why have you not defend YOUR solution? I posted reasons to > switch to testng. You make me no reply except ignoring me. > I already did. We had an extensive discussion on this during the patch development. Please read the archives. I'm not going to waste time repeating myself. In brief: * With the current solution, we can directly produce the JTreg-like output we want via our subclass and already do. From what I understand of the TestNG patch, it would produce XML and then we'd have to convert it. Exactly why is that better? * Switching to TestNG also adds a mass of dependencies which aren't needed with JUnit, making it harder for people to run the test suite. Unless you can produce a clear example of why switching to TestNG for IcedTea-Web is essential and which overrides the need for all those additional dependencies, I see no reason to drop a solution that works and has already been extensively reviewed. > J. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Apr 12 06:02:47 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 12 Apr 2011 14:02:47 +0100 Subject: removing junit as part of switching back to testng In-Reply-To: <4DA3F78E.9060606@redhat.com> References: <4DA32293.2020502@redhat.com> <20110411160334.GD13424@rivendell.middle-earth.co.uk> <4DA3F78E.9060606@redhat.com> Message-ID: <20110412130247.GI7262@rivendell.middle-earth.co.uk> On 08:56 Tue 12 Apr , Jiri Vanek wrote: > On 04/11/2011 06:03 PM, Dr Andrew John Hughes wrote: > > On 17:47 Mon 11 Apr , Jiri Vanek wrote: > >> diff -r 934543b8084d ChangeLog > >> --- a/ChangeLog Mon Apr 11 16:03:44 2011 +0100 > >> +++ b/ChangeLog Mon Apr 11 17:45:44 2011 +0200 > >> @@ -1,3 +1,7 @@ > >> +2011-04-11 Jiri Vanek > >> + > >> + * removed junit (1/2 from mooving to testNG) > >> + > >> 2011-04-08 Omair Majid > >> > >> * README: Update to add notes on rhino and junit. > > > > Why would we want to remove a perfectly working solution? > > > > We've already discusssed this at length. Please read the previous discussion. > So I can consider that as approved? Consider what approved? This patch? No. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From xranby at icedtea.classpath.org Tue Apr 12 07:08:00 2011 From: xranby at icedtea.classpath.org (xranby at icedtea.classpath.org) Date: Tue, 12 Apr 2011 14:08:00 +0000 Subject: /hg/release/icedtea6-1.9: PR689: Shark fails to find LLVM 2.9 Sy... Message-ID: changeset 495cac553ab0 in /hg/release/icedtea6-1.9 details: http://icedtea.classpath.org/hg/release/icedtea6-1.9?cmd=changeset;node=495cac553ab0 author: Xerxes R?nby date: Tue Apr 12 15:47:27 2011 +0200 PR689: Shark fails to find LLVM 2.9 System headers during build 2011-04-12 Xerxes R?nby PR689: Shark fails to find LLVM 2.9 System headers during build * Makefile.am: Add patch. * patches/shark-llvm-2.9.patch: In LLVM 2.9 System headers are moved to Support. * NEWS: Updated. diffstat: ChangeLog | 8 ++++++++ Makefile.am | 3 ++- NEWS | 2 ++ patches/shark-llvm-2.9.patch | 28 ++++++++++++++++++++++++++++ 4 files changed, 40 insertions(+), 1 deletions(-) diffs (73 lines): diff -r e4336b504f8a -r 495cac553ab0 ChangeLog --- a/ChangeLog Fri Mar 25 15:04:00 2011 -0400 +++ b/ChangeLog Tue Apr 12 15:47:27 2011 +0200 @@ -1,3 +1,11 @@ +2011-04-12 Xerxes R??nby + + PR689: Shark fails to find LLVM 2.9 System headers during build + * Makefile.am: Add patch. + * patches/shark-llvm-2.9.patch: + In LLVM 2.9 System headers are moved to Support. + * NEWS: Updated. + 2010-11-01 Deepak Bhole PR542: Plugin fails with NPE on diff -r e4336b504f8a -r 495cac553ab0 Makefile.am --- a/Makefile.am Fri Mar 25 15:04:00 2011 -0400 +++ b/Makefile.am Tue Apr 12 15:47:27 2011 +0200 @@ -340,7 +340,8 @@ patches/latent_jaxp_bug.patch \ patches/openjdk/6675802-securityExceptions-applets.patch \ patches/openjdk/6691503-malicious-applet-always-on-top.patch \ - patches/jtreg-LastErrorString.patch + patches/jtreg-LastErrorString.patch \ + patches/shark-llvm-2.9.patch if WITH_ALT_HSBUILD ICEDTEA_PATCHES += \ diff -r e4336b504f8a -r 495cac553ab0 NEWS --- a/NEWS Fri Mar 25 15:04:00 2011 -0400 +++ b/NEWS Tue Apr 12 15:47:27 2011 +0200 @@ -16,6 +16,8 @@ - S6980392, PR642: simple correction in testcase, added missing bracket * Plugin - PR542: Plugin fails with NPE on http://www.openprocessing.org/visuals/iframe.php?visualID=2615 +* Shark + - PR689: Shark fails to find LLVM 2.9 System headers during build New in release 1.9.7 (2011-02-15): diff -r e4336b504f8a -r 495cac553ab0 patches/shark-llvm-2.9.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/shark-llvm-2.9.patch Tue Apr 12 15:47:27 2011 +0200 @@ -0,0 +1,29 @@ +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp +=================================================================== +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 +@@ -43,7 +43,11 @@ + #include + #endif + #include ++#if SHARK_LLVM_VERSION >= 29 ++#include ++#else + #include ++#endif + #include + #include + #include +@@ -52,8 +56,12 @@ + #include + #include + #include ++#if SHARK_LLVM_VERSION >= 29 ++#include ++#else + #include + #endif ++#endif + + #include + From xranby at icedtea.classpath.org Tue Apr 12 07:11:42 2011 From: xranby at icedtea.classpath.org (xranby at icedtea.classpath.org) Date: Tue, 12 Apr 2011 14:11:42 +0000 Subject: /hg/release/icedtea6-1.10: PR689: Shark fails to find LLVM 2.9 S... Message-ID: changeset b142e8e007e6 in /hg/release/icedtea6-1.10 details: http://icedtea.classpath.org/hg/release/icedtea6-1.10?cmd=changeset;node=b142e8e007e6 author: Xerxes R?nby date: Tue Apr 12 15:50:57 2011 +0200 PR689: Shark fails to find LLVM 2.9 System headers during build 2011-04-12 Xerxes R?nby PR689: Shark fails to find LLVM 2.9 System headers during build * Makefile.am: Add patch. * patches/shark-llvm-2.9.patch: In LLVM 2.9 System headers are moved to Support. * NEWS: Updated. diffstat: ChangeLog | 8 ++++++++ Makefile.am | 3 ++- NEWS | 3 +++ patches/shark-llvm-2.9.patch | 28 ++++++++++++++++++++++++++++ 4 files changed, 41 insertions(+), 1 deletions(-) diffs (74 lines): diff -r 27de3493190b -r b142e8e007e6 ChangeLog --- a/ChangeLog Mon Apr 04 16:16:48 2011 +0100 +++ b/ChangeLog Tue Apr 12 15:50:57 2011 +0200 @@ -1,3 +1,11 @@ +2011-04-12 Xerxes R??nby + + PR689: Shark fails to find LLVM 2.9 System headers during build + * Makefile.am: Add patch. + * patches/shark-llvm-2.9.patch: + In LLVM 2.9 System headers are moved to Support. + * NEWS: Updated. + 2011-04-04 Andrew John Hughes * NEWS: Add 1.10.2. diff -r 27de3493190b -r b142e8e007e6 Makefile.am --- a/Makefile.am Mon Apr 04 16:16:48 2011 +0100 +++ b/Makefile.am Tue Apr 12 15:50:57 2011 +0200 @@ -329,7 +329,8 @@ patches/g356743-libpng-1.5.patch \ patches/mark_sun_toolkit_privileged_code.patch \ patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ - patches/openjdk/7031385-gcc-register-allocation-fix.patch + patches/openjdk/7031385-gcc-register-allocation-fix.patch \ + patches/shark-llvm-2.9.patch if WITH_ALT_HSBUILD ICEDTEA_PATCHES += \ diff -r 27de3493190b -r b142e8e007e6 NEWS --- a/NEWS Mon Apr 04 16:16:48 2011 +0100 +++ b/NEWS Tue Apr 12 15:50:57 2011 +0200 @@ -11,6 +11,9 @@ New in release 1.10.2 (20XX-XX-XX): +* Shark + - PR689: Shark fails to find LLVM 2.9 System headers during build. + New in release 1.10.1 (2011-04-04): * HotSpot 20 updated to b11. diff -r 27de3493190b -r b142e8e007e6 patches/shark-llvm-2.9.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/shark-llvm-2.9.patch Tue Apr 12 15:50:57 2011 +0200 @@ -0,0 +1,29 @@ +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp +=================================================================== +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 +@@ -43,7 +43,11 @@ + #include + #endif + #include ++#if SHARK_LLVM_VERSION >= 29 ++#include ++#else + #include ++#endif + #include + #include + #include +@@ -52,8 +56,12 @@ + #include + #include + #include ++#if SHARK_LLVM_VERSION >= 29 ++#include ++#else + #include + #endif ++#endif + + #include + From xranby at icedtea.classpath.org Tue Apr 12 07:17:23 2011 From: xranby at icedtea.classpath.org (xranby at icedtea.classpath.org) Date: Tue, 12 Apr 2011 14:17:23 +0000 Subject: /hg/icedtea6: PR689: Shark fails to find LLVM 2.9 System headers... Message-ID: changeset 307d19e0cca0 in /hg/icedtea6 details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=307d19e0cca0 author: Xerxes R?nby date: Tue Apr 12 15:56:56 2011 +0200 PR689: Shark fails to find LLVM 2.9 System headers during build 2011-04-12 Xerxes R?nby PR689: Shark fails to find LLVM 2.9 System headers during build * Makefile.am: Add patch. * patches/shark-llvm-2.9.patch: In LLVM 2.9 System headers are moved to Support. * NEWS: Updated. diffstat: ChangeLog | 8 ++++++++ Makefile.am | 3 ++- NEWS | 2 ++ patches/shark-llvm-2.9.patch | 28 ++++++++++++++++++++++++++++ 4 files changed, 40 insertions(+), 1 deletions(-) diffs (73 lines): diff -r ddd219edd416 -r 307d19e0cca0 ChangeLog --- a/ChangeLog Sun Apr 10 22:51:11 2011 +0200 +++ b/ChangeLog Tue Apr 12 15:56:56 2011 +0200 @@ -1,3 +1,11 @@ +2011-04-12 Xerxes R??nby + + PR689: Shark fails to find LLVM 2.9 System headers during build + * Makefile.am: Add patch. + * patches/shark-llvm-2.9.patch: + In LLVM 2.9 System headers are moved to Support. + * NEWS: Updated. + 2011-04-10 Yasumasa Suenaga * tapset/hotspot_jni.stp.in (hotspot.jni.CallNonvirtual*): diff -r ddd219edd416 -r 307d19e0cca0 Makefile.am --- a/Makefile.am Sun Apr 10 22:51:11 2011 +0200 +++ b/Makefile.am Tue Apr 12 15:56:56 2011 +0200 @@ -335,7 +335,8 @@ patches/g356743-libpng-1.5.patch \ patches/revert-6885123.patch \ patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ - patches/openjdk/7031385-gcc-register-allocation-fix.patch + patches/openjdk/7031385-gcc-register-allocation-fix.patch \ + patches/shark-llvm-2.9.patch if WITH_ALT_HSBUILD ICEDTEA_PATCHES += \ diff -r ddd219edd416 -r 307d19e0cca0 NEWS --- a/NEWS Sun Apr 10 22:51:11 2011 +0200 +++ b/NEWS Tue Apr 12 15:56:56 2011 +0200 @@ -46,6 +46,8 @@ - On ARM, force interpreter to be built in ARM mode. - MIPS: 64-bit and interpreter inlining by default. - Trivial implementation of stubs for MIPS. +* Shark + - PR689: Shark fails to find LLVM 2.9 System headers during build. New in release 1.10 (2011-XX-XX): diff -r ddd219edd416 -r 307d19e0cca0 patches/shark-llvm-2.9.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/shark-llvm-2.9.patch Tue Apr 12 15:56:56 2011 +0200 @@ -0,0 +1,29 @@ +Index: openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp +=================================================================== +--- openjdk.orig/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:48:09.270716001 +0200 ++++ openjdk/hotspot/src/share/vm/shark/llvmHeaders.hpp 2011-04-08 11:49:54.714716002 +0200 +@@ -43,7 +43,11 @@ + #include + #endif + #include ++#if SHARK_LLVM_VERSION >= 29 ++#include ++#else + #include ++#endif + #include + #include + #include +@@ -52,8 +56,12 @@ + #include + #include + #include ++#if SHARK_LLVM_VERSION >= 29 ++#include ++#else + #include + #endif ++#endif + + #include + From jvanek at redhat.com Tue Apr 12 07:17:28 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 12 Apr 2011 16:17:28 +0200 Subject: adding testng after removig of junit In-Reply-To: <20110412130140.GH7262@rivendell.middle-earth.co.uk> References: <4DA4044F.5010407@redhat.com> <4DA43139.2080505@redhat.com> <20110412123308.GF7262@rivendell.middle-earth.co.uk> <4DA448DA.4030803@redhat.com> <20110412130140.GH7262@rivendell.middle-earth.co.uk> Message-ID: <4DA45EF8.8090809@redhat.com> On 04/12/2011 03:01 PM, Dr Andrew John Hughes wrote: > On 14:43 Tue 12 Apr , Jiri Vanek wrote: >> On 04/12/2011 02:33 PM, Dr Andrew John Hughes wrote: >>> On 13:02 Tue 12 Apr , Pavel Tisnovsky wrote: >>>> Hi all, >>>> >>>> as a person who is going to regularly run the IcedTea-web tests (I'd >>>> also like to add new test cases in the near future) I'd prefer if he >>>> really began to use TestNG. >>>> >>> >>> Why? >>> >>> (BTW, I think you want 'it' not 'he' if I'm reading the above correctly >>> and you're referring to IcedTea-Web) >>> >>>> Cheers >>>> Pavel >>>> >>>> >>>> >> >> Why? It is simple. And I wrote it many times - testng have much better >> output then junit. So it is with configuration. Why are you ignoring my >> posts?! Why have you not defend YOUR solution? I posted reasons to >> switch to testng. You make me no reply except ignoring me. >> > > I already did. We had an extensive discussion on this during the patch > development. Please read the archives. I'm not going to waste time > repeating myself. I read it deeply. Don't worry. I just had late reaction:-/ (my fault-but it was just a day after commit). > > In brief: > > * With the current solution, we can directly produce the JTreg-like > output we want via our subclass and already do. From what I > understand of the TestNG patch, it would produce XML and then we'd > have to convert it. Exactly why is that better? Because we DO NOT want jtreg like result. Pavel is doing magic to create reports as are now from such a bad output. From xml - we have all informations. Pavel will use it to produce reports containing stack traces, will be able to see directly which ones should fail and which should pass. Will be able to separate groups,Will be able to create very solid statistics, and whatever we can imagine. It is pitty to lost all the information. jtreg-like is just poor summary - and without ant it is probably impossible to reach something better. Another advance is extreme configurability (see bottom). > > * Switching to TestNG also adds a mass of dependencies which aren't > needed with JUnit, making it harder for people to run the test suite. > testng are three jars. Junit is one jar. I do not see difference whether wee need to make special steps to add one jar to classpath or three. Al four of them are easily to be found and downloaded. And all are packaged in fedora (an in most of distros). > Unless you can produce a clear example of why switching to TestNG > for IcedTea-Web is essential and which overrides the need for all > those additional dependencies, I see no reason to drop a solution that > works and has already been extensively reviewed. > What I see essential is output of test framework and configureability. junit is not about to be run from commadline. It is ant tool. And we do not want ant for sure (we have make). You will probably never use or run this test. Me, Pavel and Omair will do it most of time. And for myself i really wont to configure what i'm running. This Luncher class and makefile "send all classes to classpath" is dreadfull hack. Btw.. I have already posted all of those dis/advantages;) >> J. > -------------- next part -------------- A non-text attachment was scrubbed... Name: tests-output.tar.gz Type: application/x-gzip Size: 11234 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/1e969d3b/tests-output.tar.gz From xerxes at zafena.se Tue Apr 12 07:27:45 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 12 Apr 2011 16:27:45 +0200 Subject: RFC: PR698 Shark failes to find LLVM 2.9 System headers during build In-Reply-To: <20110412122736.GD7262@rivendell.middle-earth.co.uk> References: <4DA43496.5080409@zafena.se> <20110412122736.GD7262@rivendell.middle-earth.co.uk> Message-ID: <4DA46161.6030709@zafena.se> On 2011-04-12 14:20, Gary Benson wrote: > Hi Xerxes, > > The patches look good to me. Would you be able to submit them > upstream too? I can walk you through the process if you like. > > Thanks, > Gary Thanks, I want to submit this patch upstream. I do like to get advise on how to push this through the OpenJDK upstream process. I have filed the SCA. On 2011-04-12 14:27, Dr Andrew John Hughes wrote: > On 13:16 Tue 12 Apr , Xerxes R?nby wrote: >> In LLVM 2.9 >> llvm/System/Threading.h and llvm/System/Host.h >> have been moved to >> llvm/Support/Threading.h and llvm/Support/Host.h >> >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=689 >> >> The attached patches use SHARK_LLVM_VERSION to include Support/*.h for LLVM 2.9 >> and later and still includes System/*.h for older LLVM releases. >> >> Ok to commit all attached patches to: >> Icedtea6-1.9 ? >> >> Icedtea6-1.10 ? >> >> Icedtea6 trunk? >> > There is a typo in NEWS: failes -> fails. Thank you! I have now fixed this. > I'm also getting question marks in your surname in the ChangeLog. I think my email client have picked the wrong mime type for the attachments Content-Type: text/x-patch; The patch itself contains UTF-8. if my client would have added the attachment as Content-Type: text/x-patch; charset=UTF-8; then I think my surname would have looked ok inside your client. My surname looks ok with an "?" If I download the attachment and then view it using gedit/vi etc... > Otherwise, the change looks good for all three branches. > > Why not 1.8 too? There was quite a lot of Shark fixes between 1.8 and 1.9. 1.9 Contains the first Shark release that passed the TCK. 1.8 Contains the working ARM Thumb2 JIT that will break if I back-port all the Shark fixes that went into 1.9. I have pushed to: http://icedtea.classpath.org/hg/release/icedtea6-1.9/rev/495cac553ab0 http://icedtea.classpath.org/hg/release/icedtea6-1.10/rev/b142e8e007e6 http://icedtea.classpath.org/hg/icedtea6/rev/307d19e0cca0 ps. my surname looks ok if i view the Changelog after checking out the sources instead of using the web-frontend. Cheers Xerxes From gbenson at redhat.com Tue Apr 12 08:28:43 2011 From: gbenson at redhat.com (Gary Benson) Date: Tue, 12 Apr 2011 16:28:43 +0100 Subject: RFC: PR698 Shark failes to find LLVM 2.9 System headers during build In-Reply-To: <4DA46161.6030709@zafena.se> References: <4DA43496.5080409@zafena.se> <20110412122736.GD7262@rivendell.middle-earth.co.uk> <4DA46161.6030709@zafena.se> Message-ID: <20110412152842.GD2656@redhat.com> Xerxes R?nby wrote: > On 2011-04-12 14:20, Gary Benson wrote: > > The patches look good to me. Would you be able to submit them > > upstream too? I can walk you through the process if you like. > > I want to submit this patch upstream. > I do like to get advise on how to push this through the OpenJDK > upstream process. > I have filed the SCA. Ok, first you need to get a copy of the jdk7/hotspot-comp repo: hg clone http://hg.openjdk.java.net/jdk7/hotspot-comp/ cd hotspot-comp sh get_source.sh Then you need to apply your patch to it: patch -p2 < /path/to/icedtea6/patches/shark-llvm-2.9.patch Then you need to make the webrev: ksh make/scripts/webrev.ksh -fN That will create a directory called "webrev" and a file called "webrev.zip" (which is just the directory zipped up). You need to put that directory on a website somewhere. Do you have a website you can use? Once you've done that, subscribe to hotspot-compiler-dev: http://mail.openjdk.java.net/mailman/listinfo/hotspot-compiler-dev and post a message something like this one: http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/004957.html Hopefully someone there will pick it up :) Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Tue Apr 12 08:53:07 2011 From: gbenson at redhat.com (Gary Benson) Date: Tue, 12 Apr 2011 16:53:07 +0100 Subject: RFC: PR698 Shark failes to find LLVM 2.9 System headers during build In-Reply-To: <20110412152842.GD2656@redhat.com> References: <4DA43496.5080409@zafena.se> <20110412122736.GD7262@rivendell.middle-earth.co.uk> <4DA46161.6030709@zafena.se> <20110412152842.GD2656@redhat.com> Message-ID: <20110412155307.GE2656@redhat.com> Gary Benson wrote: > patch -p2 < /path/to/icedtea6/patches/shark-llvm-2.9.patch -p1 -- http://gbenson.net/ From dlila at redhat.com Tue Apr 12 09:19:45 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 12:19:45 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1812312265.183301.1302625172372.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <396380384.183308.1302625185663.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. I found a few problems in PluginAppletViewer.java. We were modifying/reading from two static hash maps concurrently. The hash maps were "applets" and "status". status was only modified in a synchronized method, but we were reading from it outside of that method and that's unsafe. As far as I can tell, there are no group of operations that need to happen atomically, so using ConcurrentHashMaps should be enough. I've also done a bit of refactoring (removing dead code, adding some SuppressWarnings annotations, making members private, etc). Any criticism is appreciated. Thank you, Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: PAVConcur.patch Type: text/x-patch Size: 11481 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/d5c648e9/PAVConcur.patch From asu at redhat.com Tue Apr 12 09:49:25 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 12 Apr 2011 12:49:25 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <396380384.183308.1302625185663.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <365200016.48633.1302626965305.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > Hi. > > I found a few problems in PluginAppletViewer.java. > We were modifying/reading from two static hash maps > concurrently. The hash maps were "applets" and "status". > status was only modified in a synchronized method, > but we were reading from it outside of that method and > that's unsafe. > > As far as I can tell, there are no group of operations > that need to happen atomically, so using ConcurrentHashMaps > should be enough. > > I've also done a bit of refactoring (removing dead code, > adding some SuppressWarnings annotations, making members > private, etc). > > Any criticism is appreciated. > Hi Denis, I think the clean-up should go in its own patch. Seems like an extra space @ @@ -1645,7 +1587,8 @@ new Thread(new Runnable() { - public void run() + @SuppressWarnings("deprecation") + public void run() { ClassLoader cl = p.applet.getClass().getClassLoader(); Cheers, Andrew From dlila at redhat.com Tue Apr 12 09:50:21 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 12:50:21 -0400 (EDT) Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <20110408002826.GE32676@rivendell.middle-earth.co.uk> Message-ID: <1480987931.188008.1302627021361.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi Andrew. I'm sorry it took so long to answer this. I've been busy with a few other things. > No, this isn't enough. This piece of code: > > private URL findBestUrl(Resource resource) { > 1. DownloadOptions options = downloadOptions.get(resource); > 2. if (options == null) { > 3. options = new DownloadOptions(false, false); > } > > may be subject to a race from addResource. Line 1 may retrieve null, > but that thread may then be interrupted before line 2 can be executed. > In the meantime, the resource could be added to downloadOptions and > this thread would still have the old stale value. I don't think this is a problem findBestUrl never races with addResource. It's only called from initializeResource, which isn't called unless the resource has been already added. > It's also odd code in that this new instance is created but not stored > in the map. So it seems possible that many threads could call this > method, all get a return value of null and create new instances of > DownloadOptions. The control flow in this class is not very clear, > but I presume the null check means that there is a possibility that > this method can be called before the resource is added in addResource. > > I would suggest replacing those three lines with: > > DownloadOptions options = downloadOptions.putIfAbsent(resource, new > DownloadOptions(false,false)); I agree that it's odd, but this code has deadlocks in it and it's far more complex than necessary so a lot of it will be re-written. I would like to wait until that happens before pushing something like your suggestion, because it is likely to become unecessary. Regards, Denis. ----- Original Message ----- > On 12:13 Tue 05 Apr , Denis Lila wrote: > > Hi. > > > > I think I found a concurrency problem in > > ResourceTracker.addResource. This method is not static. > > It is called from different threads, and it writes to > > downloadOptions which is a static HashMap. This is not > > safe. The patch uses a ConcurrentHashMap. That should > > be enough to fix it. > > > > Ok to push? > > > > Regards, > > Denis. > > > > This ensures, atomically, that any existing value is retrieved and > stored > in options, but if one is not present, the default is added and > returned. > With addResource using put instead of putIfAbsent, it should still > override > a default added by this method. > > This also means there's a reason to follow Andrew's suggestion, as > putIfAbsent is unique to ConcurrentHashMap. In general, the interface > type (Map) should be used rather than the specific type to allow easy > transition between different implementations. It prevents code using > implementation-specific methods which would make later implementation > changes harder e.g. if this class had been using HashMap directly, it > may have relied on HashMap-only methods. > > > diff -r 62011060e7ea ChangeLog > > --- a/ChangeLog Tue Apr 05 12:07:10 2011 -0400 > > +++ b/ChangeLog Tue Apr 05 12:12:33 2011 -0400 ... From dbhole at redhat.com Tue Apr 12 10:10:55 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 12 Apr 2011 13:10:55 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <396380384.183308.1302625185663.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1812312265.183301.1302625172372.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <396380384.183308.1302625185663.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110412171054.GA27867@redhat.com> * Denis Lila [2011-04-12 12:21]: > Hi. > > I found a few problems in PluginAppletViewer.java. > We were modifying/reading from two static hash maps > concurrently. The hash maps were "applets" and "status". > status was only modified in a synchronized method, > but we were reading from it outside of that method and > that's unsafe. > It is unsafe to read only if we iterate over it, which we don't. ConcurrentHapMap does not lock when retrieving either. From the JavaDocs: "However, even though all operations are thread-safe, retrieval operations do not entail locking ..." So status is ok. applets map is written to unsynch. though, so that needs to be fixed. Not through ConcurrentMap though IMO. I have commented on it below. > As far as I can tell, there are no group of operations > that need to happen atomically, so using ConcurrentHashMaps > should be enough. > > I've also done a bit of refactoring (removing dead code, > adding some SuppressWarnings annotations, making members > private, etc). > > Any criticism is appreciated. > > Thank you, > Denis. > > - // Applet initialized. Find out it's classloader and add it to the list > - String portComponent = doc.getPort() != -1 ? ":" + doc.getPort() : ""; > - String codeBase = doc.getProtocol() + "://" + doc.getHost() + portComponent; > - > - if (atts.get("codebase") != null) { > - try { > - URL appletSrcURL = new URL(codeBase + atts.get("codebase")); > - codeBase = appletSrcURL.getProtocol() + "://" + appletSrcURL.getHost(); > - } catch (MalformedURLException mfue) { > - // do nothing > - } > - } > - > - // Wait for the panel to initialize > - // (happens in a separate thread) > - Applet a; > - > // Wait for panel to come alive > int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > int wait = 0; > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait < maxWait)) { > + while (!panel.isAlive() && wait < maxWait) { > try { > Thread.sleep(50); > wait += 50; You have discarded the check for panel == null. Why? > - private static HashMap applets = > - new HashMap(); > + static ConcurrentMap applets = > + new ConcurrentHashMap(); > > private static PluginStreamHandler streamhandler; > > private static PluginCallRequestFactory requestFactory; > > - private static HashMap status = > - new HashMap(); > + private static ConcurrentMap status = > + new ConcurrentHashMap(); > As mentioned above, status is OK as a HashMap. I think rather than making applets a ConcurrentMap, write to it should be synchronized instead. The map is written to only in one location, and it happens only once per applet init, so race for it will be rare. OTOH, we read it in many places, and since ConcurrentHashMap does not guarantee non-blocking read in perpetuity, I think we should avoid it. > > - static Vector appletPanels = new Vector(); > + private static Vector appletPanels = new Vector(); > I haven't looked into this part of the code before, but from what I can see now, there appears to be a synchronization issue here too. We use elements() which does not shield against concurrent modification. Worse yet, it is not fail-fast so it could end up using bad data silently. Iterator read and element write to appletPanels should be synchronized around the instance. > @@ -1645,7 +1587,8 @@ > > new Thread(new Runnable() > { > - public void run() > + @SuppressWarnings("deprecation") > + public void run() The SuppressWarnings annotation is indented one more than the start of the method below. One of those 2 indents is wrong. Cheers, Deepak From dbhole at redhat.com Tue Apr 12 10:13:14 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 12 Apr 2011 13:13:14 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <365200016.48633.1302626965305.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <396380384.183308.1302625185663.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <365200016.48633.1302626965305.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110412171314.GC27867@redhat.com> * Andrew Su [2011-04-12 12:50]: > > > ----- Original Message ----- > > Hi. > > > > I found a few problems in PluginAppletViewer.java. > > We were modifying/reading from two static hash maps > > concurrently. The hash maps were "applets" and "status". > > status was only modified in a synchronized method, > > but we were reading from it outside of that method and > > that's unsafe. > > > > As far as I can tell, there are no group of operations > > that need to happen atomically, so using ConcurrentHashMaps > > should be enough. > > > > I've also done a bit of refactoring (removing dead code, > > adding some SuppressWarnings annotations, making members > > private, etc). > > > > Any criticism is appreciated. > > > > Hi Denis, > > I think the clean-up should go in its own patch. > Doh. Planned to write this at the very end and I forgot :/ ... yes, please split cleanup and concurrency fixes into separate patches. Cheers, Deepak > Seems like an extra space @ > > @@ -1645,7 +1587,8 @@ > > new Thread(new Runnable() > { > - public void run() > + @SuppressWarnings("deprecation") > + public void run() > { > ClassLoader cl = p.applet.getClass().getClassLoader(); > > Cheers, > Andrew > From jvanek at redhat.com Tue Apr 12 10:59:01 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Tue, 12 Apr 2011 19:59:01 +0200 Subject: Fwd: Re: adding testng after removig of junit Message-ID: <4DA492E5.7050200@redhat.com> -------- Original Message -------- Subject: Re: adding testng after removig of junit Date: Tue, 12 Apr 2011 16:17:28 +0200 From: Jiri Vanek To: distro-pkg-dev at openjdk.java.net On 04/12/2011 03:01 PM, Dr Andrew John Hughes wrote: > On 14:43 Tue 12 Apr , Jiri Vanek wrote: >> On 04/12/2011 02:33 PM, Dr Andrew John Hughes wrote: >>> On 13:02 Tue 12 Apr , Pavel Tisnovsky wrote: >>>> Hi all, >>>> >>>> as a person who is going to regularly run the IcedTea-web tests (I'd >>>> also like to add new test cases in the near future) I'd prefer if he >>>> really began to use TestNG. >>>> >>> >>> Why? >>> >>> (BTW, I think you want 'it' not 'he' if I'm reading the above correctly >>> and you're referring to IcedTea-Web) >>> >>>> Cheers >>>> Pavel >>>> >>>> >>>> >> >> Why? It is simple. And I wrote it many times - testng have much better >> output then junit. So it is with configuration. Why are you ignoring my >> posts?! Why have you not defend YOUR solution? I posted reasons to >> switch to testng. You make me no reply except ignoring me. >> > > I already did. We had an extensive discussion on this during the patch > development. Please read the archives. I'm not going to waste time > repeating myself. I read it deeply. Don't worry. I just had late reaction:-/ (my fault-but it was just a day after commit). > > In brief: > > * With the current solution, we can directly produce the JTreg-like > output we want via our subclass and already do. From what I > understand of the TestNG patch, it would produce XML and then we'd > have to convert it. Exactly why is that better? Because we DO NOT want jtreg like result. Pavel is doing magic to create reports as are now from such a bad output. From xml - we have all informations. Pavel will use it to produce reports containing stack traces, will be able to see directly which ones should fail and which should pass. Will be able to separate groups,Will be able to create very solid statistics, and whatever we can imagine. It is pitty to lost all the information. jtreg-like is just poor summary - and without ant it is probably impossible to reach something better. Another advance is extreme configurability (see bottom). > > * Switching to TestNG also adds a mass of dependencies which aren't > needed with JUnit, making it harder for people to run the test suite. > testng are three jars. Junit is one jar. I do not see difference whether wee need to make special steps to add one jar to classpath or three. Al four of them are easily to be found and downloaded. And all are packaged in fedora (an in most of distros). > Unless you can produce a clear example of why switching to TestNG > for IcedTea-Web is essential and which overrides the need for all > those additional dependencies, I see no reason to drop a solution that > works and has already been extensively reviewed. > What I see essential is output of test framework and configureability. junit is not about to be run from commadline. It is ant tool. And we do not want ant for sure (we have make). You will probably never use or run this test. Me, Pavel and Omair will do it most of time. And for myself i really wont to configure what i'm running. This Luncher class and makefile "send all classes to classpath" is dreadfull hack. Btw.. I have already posted all of those dis/advantages;) >> J. > -------------- next part -------------- A non-text attachment was scrubbed... Name: tests-output.tar.gz Type: application/x-gzip Size: 11234 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/f93fd2c7/tests-output.tar.gz From dlila at redhat.com Tue Apr 12 11:54:30 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 14:54:30 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412171054.GA27867@redhat.com> Message-ID: <1343507594.190352.1302634470659.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > You have discarded the check for panel == null. Why? Because it's a local variable. If it's null, that's an infinite loop. Also, if it's null, it can't get there anyway, because an NPE would be thrown a few lines prior. > It is unsafe to read only if we iterate over it, which we don't. > ConcurrentHapMap does not lock when retrieving either. From the > JavaDocs: > > "However, even though all operations are thread-safe, retrieval > operations do not entail locking ..." > > So status is ok. > As mentioned above, status is OK as a HashMap. I think rather than > making applets a ConcurrentMap, write to it should be synchronized > instead. The map is written to only in one location, and it happens > only > once per applet init, so race for it will be rare. OTOH, we read it in > many places, and since ConcurrentHashMap does not guarantee > non-blocking > read in perpetuity, I think we should avoid it. I don't think status is ok, and I don't think synchronizing only the writes to applets is right. The docs for HashMap say "If multiple threads access a hash map concurrently, and at least one of the threads modifies the map structurally, it must be synchronized externally". We satisfy these requirements so we must use a ConcurrentHashMap (or do our own locking). The reason for this is that HashMap was not build with concurrent access in mind and it's not safe for "get" to be traversing the internal data structures of the map while some other thread is modifying these data structures. For example: suppose a map is implemented by chaining, and suppose we have a concurrent get(x) and remove(y) in progress. Suppose also that x.hashCode()==y.hashCode(), so they're in the same chain, and that x is after y in the chain. y is removed from the chain with a sequence of operations like this: p = y.prev n = y.next p.next = n n.prev = p y.prev = null y.next = null Now, the chain traversal in get(x) could get to p when p.next == y, so then it goes to y, but then y.next=null could execute, and get(x) will think that the end of the chain has been reached and it will wrongly return null. > > - static Vector appletPanels = new > > Vector(); > > + private static Vector appletPanels = new > > Vector(); > > > > I haven't looked into this part of the code before, but from what I > can > see now, there appears to be a synchronization issue here too. We use > elements() which does not shield against concurrent modification. > Worse > yet, it is not fail-fast so it could end up using bad data silently. > > Iterator read and element write to appletPanels should be synchronized > around the instance. That's a good point. I completely forgot we were iterating through it. We also need to synchronize a read earlier because we do "if(!contains) put" and those 2 operations need to be atomic. > The SuppressWarnings annotation is indented one more than the start of > the method below. One of those 2 indents is wrong. Yeah, Andrew pointed this out. I'm not sure how it happened (I let eclipse do this sort of thing). I'll split the patch in 2 parts and send those in a few minutes. Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-12 12:21]: > > Hi. > > > > I found a few problems in PluginAppletViewer.java. > > We were modifying/reading from two static hash maps > > concurrently. The hash maps were "applets" and "status". > > status was only modified in a synchronized method, > > but we were reading from it outside of that method and > > that's unsafe. > > > applets map is written to unsynch. though, so that > needs to be fixed. Not through ConcurrentMap though IMO. I have > commented on it below. > > > As far as I can tell, there are no group of operations > > that need to happen atomically, so using ConcurrentHashMaps > > should be enough. > > > > I've also done a bit of refactoring (removing dead code, > > adding some SuppressWarnings annotations, making members > > private, etc). > > > > Any criticism is appreciated. > > > > Thank you, > > Denis. > > > > > > - // Applet initialized. Find out it's classloader and add it to the > > list > > - String portComponent = doc.getPort() != -1 ? ":" + doc.getPort() : > > ""; > > - String codeBase = doc.getProtocol() + "://" + doc.getHost() + > > portComponent; > > - > > - if (atts.get("codebase") != null) { > > - try { > > - URL appletSrcURL = new URL(codeBase + atts.get("codebase")); > > - codeBase = appletSrcURL.getProtocol() + "://" + > > appletSrcURL.getHost(); > > - } catch (MalformedURLException mfue) { > > - // do nothing > > - } > > - } > > - > > - // Wait for the panel to initialize > > - // (happens in a separate thread) > > - Applet a; > > - > > // Wait for panel to come alive > > int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait > > for panel to come alive > > int wait = 0; > > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait > > < maxWait)) { > > + while (!panel.isAlive() && wait < maxWait) { > > try { > > Thread.sleep(50); > > wait += 50; > > > > > - private static HashMap applets = > > - new HashMap(); > > + static ConcurrentMap applets = > > + new ConcurrentHashMap(); > > > > private static PluginStreamHandler streamhandler; > > > > private static PluginCallRequestFactory requestFactory; > > > > - private static HashMap status = > > - new HashMap(); > > + private static ConcurrentMap status = > > + new ConcurrentHashMap(); > > > > > > > > > > > > @@ -1645,7 +1587,8 @@ > > > > new Thread(new Runnable() > > { > > - public void run() > > + @SuppressWarnings("deprecation") > > + public void run() > > > Cheers, > Deepak From dlila at redhat.com Tue Apr 12 12:23:01 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 15:23:01 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412171054.GA27867@redhat.com> Message-ID: <2069904858.196062.1302636181494.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. I already replied to this e-mail, but I didn't get it, so I'm assuming there are others who didn't. The reply is here: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013537.html In it I gave reasons for why I think the attached patch is the correct way to do things. Is it good to go? Thank you, Denis. ----- Original Message ----- > * Denis Lila [2011-04-12 12:21]: > > Hi. > > > > I found a few problems in PluginAppletViewer.java. > > We were modifying/reading from two static hash maps > > concurrently. The hash maps were "applets" and "status". > > status was only modified in a synchronized method, ... From dlila at redhat.com Tue Apr 12 12:23:25 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 15:23:25 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412171054.GA27867@redhat.com> Message-ID: <1729717679.196075.1302636205757.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Eh, I forgot the attachment. ----- Original Message ----- > * Denis Lila [2011-04-12 12:21]: > > Hi. > > > > I found a few problems in PluginAppletViewer.java. > > We were modifying/reading from two static hash maps > > concurrently. The hash maps were "applets" and "status". > > status was only modified in a synchronized method, > > but we were reading from it outside of that method and > > that's unsafe. > > > > It is unsafe to read only if we iterate over it, which we don't. > ConcurrentHapMap does not lock when retrieving either. From the > JavaDocs: > > "However, even though all operations are thread-safe, retrieval > operations do not entail locking ..." > > So status is ok. applets map is written to unsynch. though, so that > needs to be fixed. Not through ConcurrentMap though IMO. I have > commented on it below. > > > As far as I can tell, there are no group of operations > > that need to happen atomically, so using ConcurrentHashMaps > > should be enough. > > > > I've also done a bit of refactoring (removing dead code, > > adding some SuppressWarnings annotations, making members > > private, etc). > > > > Any criticism is appreciated. > > > > Thank you, > > Denis. > > > > > > - // Applet initialized. Find out it's classloader and add it to the > > list > > - String portComponent = doc.getPort() != -1 ? ":" + doc.getPort() : > > ""; > > - String codeBase = doc.getProtocol() + "://" + doc.getHost() + > > portComponent; > > - > > - if (atts.get("codebase") != null) { > > - try { > > - URL appletSrcURL = new URL(codeBase + atts.get("codebase")); > > - codeBase = appletSrcURL.getProtocol() + "://" + > > appletSrcURL.getHost(); > > - } catch (MalformedURLException mfue) { > > - // do nothing > > - } > > - } > > - > > - // Wait for the panel to initialize > > - // (happens in a separate thread) > > - Applet a; > > - > > // Wait for panel to come alive > > int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait > > for panel to come alive > > int wait = 0; > > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait > > < maxWait)) { > > + while (!panel.isAlive() && wait < maxWait) { > > try { > > Thread.sleep(50); > > wait += 50; > > > You have discarded the check for panel == null. Why? > > > - private static HashMap applets = > > - new HashMap(); > > + static ConcurrentMap applets = > > + new ConcurrentHashMap(); > > > > private static PluginStreamHandler streamhandler; > > > > private static PluginCallRequestFactory requestFactory; > > > > - private static HashMap status = > > - new HashMap(); > > + private static ConcurrentMap status = > > + new ConcurrentHashMap(); > > > > As mentioned above, status is OK as a HashMap. I think rather than > making applets a ConcurrentMap, write to it should be synchronized > instead. The map is written to only in one location, and it happens > only > once per applet init, so race for it will be rare. OTOH, we read it in > many places, and since ConcurrentHashMap does not guarantee > non-blocking > read in perpetuity, I think we should avoid it. > > > > > > > - static Vector appletPanels = new > > Vector(); > > + private static Vector appletPanels = new > > Vector(); > > > > I haven't looked into this part of the code before, but from what I > can > see now, there appears to be a synchronization issue here too. We use > elements() which does not shield against concurrent modification. > Worse > yet, it is not fail-fast so it could end up using bad data silently. > > Iterator read and element write to appletPanels should be synchronized > around the instance. > > > > @@ -1645,7 +1587,8 @@ > > > > new Thread(new Runnable() > > { > > - public void run() > > + @SuppressWarnings("deprecation") > > + public void run() > > The SuppressWarnings annotation is indented one more than the start of > the method below. One of those 2 indents is wrong. > > Cheers, > Deepak -------------- next part -------------- A non-text attachment was scrubbed... Name: PAVConcurrency_v2.patch Type: text/x-patch Size: 5585 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/41e97af6/PAVConcurrency_v2.patch From ahughes at redhat.com Tue Apr 12 12:29:04 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 12 Apr 2011 20:29:04 +0100 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <365200016.48633.1302626965305.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <396380384.183308.1302625185663.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <365200016.48633.1302626965305.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110412192904.GJ7262@rivendell.middle-earth.co.uk> On 12:49 Tue 12 Apr , Andrew Su wrote: > > > ----- Original Message ----- > > Hi. > > > > I found a few problems in PluginAppletViewer.java. > > We were modifying/reading from two static hash maps > > concurrently. The hash maps were "applets" and "status". > > status was only modified in a synchronized method, > > but we were reading from it outside of that method and > > that's unsafe. > > > > As far as I can tell, there are no group of operations > > that need to happen atomically, so using ConcurrentHashMaps > > should be enough. > > > > I've also done a bit of refactoring (removing dead code, > > adding some SuppressWarnings annotations, making members > > private, etc). > > > > Any criticism is appreciated. > > > > Hi Denis, > > I think the clean-up should go in its own patch. > > Seems like an extra space @ > > @@ -1645,7 +1587,8 @@ > > new Thread(new Runnable() > { > - public void run() > + @SuppressWarnings("deprecation") > + public void run() > { > ClassLoader cl = p.applet.getClass().getClassLoader(); > > Cheers, > Andrew > +1 Please repost the concurrency concerns separate from the cleanup. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From asu at redhat.com Tue Apr 12 12:50:55 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 12 Apr 2011 15:50:55 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <2069904858.196062.1302636181494.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <803366423.53849.1302637855022.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > Hi. > > I already replied to this e-mail, but I didn't get it, > so I'm assuming there are others who didn't. The reply > is here: > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013537.html > > In it I gave reasons for why I think the attached patch > is the correct way to do things. > > Is it good to go? Deepak is right, ConcurrentHashMap doesn't lock on retrieval of value. So it is still possible that we could be trying to write and read at the same time. I propose to wrap the calls to status.get(identifier) in a synchronized method (preferably synchronizing on the object being affected [status]). Similarly, you would need to change updateStatus to synchronize on status as well. This would get rid of the problem with read while writing. -- snip -- Cheers, Andrew > > Thank you, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-12 12:21]: > > > Hi. > > > > > > I found a few problems in PluginAppletViewer.java. > > > We were modifying/reading from two static hash maps > > > concurrently. The hash maps were "applets" and "status". > > > status was only modified in a synchronized method, > ... From dlila at redhat.com Tue Apr 12 13:00:41 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 16:00:41 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <803366423.53849.1302637855022.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <186950791.196822.1302638441560.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Deepak is right, ConcurrentHashMap doesn't lock on retrieval of value. > So it is still possible that we could be trying to write and read at > the same time. > I propose to wrap the calls to status.get(identifier) in a > synchronized method (preferably synchronizing on the object being > affected [status]). Similarly, you would need to change updateStatus > to synchronize on status as well. This would get rid of the problem > with read while writing. It doesn't lock, but that's ok. Concurrent reads and writes are safe with ConcurrentHashMaps. Regards, Denis. ----- Original Message ----- > ----- Original Message ----- > > Hi. > > > > I already replied to this e-mail, but I didn't get it, > > so I'm assuming there are others who didn't. The reply > > is here: > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013537.html > > > > In it I gave reasons for why I think the attached patch > > is the correct way to do things. > > > > Is it good to go? > > > -- snip -- > > Cheers, > Andrew > > > > > Thank you, > > Denis. > > > > ----- Original Message ----- > > > * Denis Lila [2011-04-12 12:21]: > > > > Hi. > > > > > > > > I found a few problems in PluginAppletViewer.java. > > > > We were modifying/reading from two static hash maps > > > > concurrently. The hash maps were "applets" and "status". > > > > status was only modified in a synchronized method, > > ... From dbhole at redhat.com Tue Apr 12 13:01:59 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 12 Apr 2011 16:01:59 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1343507594.190352.1302634470659.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110412171054.GA27867@redhat.com> <1343507594.190352.1302634470659.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110412200159.GD27867@redhat.com> * Denis Lila [2011-04-12 14:54]: > > You have discarded the check for panel == null. Why? > > Because it's a local variable. If it's null, that's an > infinite loop. Also, if it's null, it can't get > there anyway, because an NPE would be thrown a few lines > prior. > Ah okay, seems like that code was copied and pasted from elsewhere. The panel == null check occurs in multiple places. > > It is unsafe to read only if we iterate over it, which we don't. > > ConcurrentHapMap does not lock when retrieving either. From the > > JavaDocs: > > > > "However, even though all operations are thread-safe, retrieval > > operations do not entail locking ..." > > > > So status is ok. > > > As mentioned above, status is OK as a HashMap. I think rather than > > making applets a ConcurrentMap, write to it should be synchronized > > instead. The map is written to only in one location, and it happens > > only > > once per applet init, so race for it will be rare. OTOH, we read it in > > many places, and since ConcurrentHashMap does not guarantee > > non-blocking > > read in perpetuity, I think we should avoid it. > > I don't think status is ok, and I don't think synchronizing only the > writes to applets is right. The docs for HashMap say "If multiple > threads access a hash map concurrently, and at least one of the > threads modifies the map structurally, it must be synchronized > externally". We satisfy these requirements so we must use a > ConcurrentHashMap (or do our own locking). The reason for this is > that HashMap was not build with concurrent access in mind and it's > not safe for "get" to be traversing the internal data structures > of the map while some other thread is modifying these data > structures. > > For example: > suppose a map is implemented by chaining, and suppose we have a > concurrent get(x) and remove(y) in progress. Suppose also that > x.hashCode()==y.hashCode(), so they're in the same chain, and that > x is after y in the chain. y is removed from the chain with a > sequence of operations like this: > p = y.prev > n = y.next > p.next = n > n.prev = p > y.prev = null > y.next = null > > Now, the chain traversal in get(x) could get to p when p.next == y, > so then it goes to y, but then y.next=null could execute, and get(x) > will think that the end of the chain has been reached and it will > wrongly return null. > Perhaps I should have clarified a it more -- I couldn't come up with negative consequences in *our* case as we use integer keys which hash to themselves, so there would never be any lower level buckets to worry about. So essentially we are using HashMap as an indexed list where an index will have only one element and it is never clobbered. That said, your point about making an assumption about the internal implementation is a valid concern. Though we are safe now, there is no guarantee of it in the future. > > I'll split the patch in 2 parts and send those in a few minutes. > OK. Deepak From ahughes at redhat.com Tue Apr 12 13:09:47 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 12 Apr 2011 21:09:47 +0100 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1729717679.196075.1302636205757.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110412171054.GA27867@redhat.com> <1729717679.196075.1302636205757.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110412200947.GL7262@rivendell.middle-earth.co.uk> On 15:23 Tue 12 Apr , Denis Lila wrote: snip... > diff -r 934543b8084d ChangeLog > --- a/ChangeLog Mon Apr 11 16:03:44 2011 +0100 > +++ b/ChangeLog Tue Apr 12 11:18:57 2011 -0400 > @@ -1,3 +1,13 @@ > +2011-04-12 Denis Lila > + > + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > + (applets, status): Make concurrent. > + (PluginAppletViewer): Synchronize appletPanels addElement. > + (destroyApplet): Remove applets.containsKey because it and the > + get that followed it were not atomic. > + (appletPanels): Privatize. > + (getApplet, getApplets): Synchronize iteration. > + > 2011-04-08 Omair Majid > > * README: Update to add notes on rhino and junit. > diff -r 934543b8084d plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Apr 11 16:03:44 2011 +0100 > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Tue Apr 12 11:18:57 2011 -0400 > @@ -103,6 +103,8 @@ > import java.util.List; > import java.util.Map; > import java.util.Vector; > +import java.util.concurrent.ConcurrentHashMap; > +import java.util.concurrent.ConcurrentMap; > > import javax.swing.SwingUtilities; > > @@ -340,15 +342,15 @@ > new HashMap(); > > // Instance identifier -> PluginAppletViewer object. > - private static HashMap applets = > - new HashMap(); > + private static ConcurrentMap applets = > + new ConcurrentHashMap(); > I don't think this is enough. There are a number of cases where the applets collection is misused. 1. while (!applets.containsKey(identifier) && // Map is populated only by reFrame (wait < maxWait)) { try { Thread.sleep(50); wait += 50; } catch (InterruptedException ie) { // just wait } } Surely this should be a timed wait and additions to applets should be accompanied by a notifyAll? 2. PluginAppletViewer oldFrame = applets.get(identifier); // We should not try to destroy an applet during // initialization. It may cause an inconsistent state, // which would bad if it's a trusted applet that // read/writes to files waitForAppletInit((NetxPanel) applets.get(identifier).panel); The two get calls could retrieve different values if a put occurs in the interim. 3. // Wait till initialization finishes while (!applets.containsKey(identifier) && ( !status.containsKey(identifier) || status.get(identifier).equals(PAV_INIT_STATUS.PRE_INIT) )) ; Again, this busy loop would be better waiting on a notification that the applet has been initialised. 4. // Wait till initialization finishes while (!applets.containsKey(identifier) && ( !status.containsKey(identifier) || status.get(identifier).equals(PAV_INIT_STATUS.PRE_INIT) )) ; // don't bother processing further for inactive applets if (status.get(identifier).equals(PAV_INIT_STATUS.INACTIVE)) return; applets.get(identifier).handleMessage(reference, message); Why the multiple get calls? There is the potential for these to return different values. 5. final int fIdentifier = identifier; SwingUtilities.invokeLater(new Runnable() { public void run() { applets.get(fIdentifier).appletClose(); } }); fIndentifier could point to a different applet. Why not just retain a reference to the applet? > private static PluginStreamHandler streamhandler; > > private static PluginCallRequestFactory requestFactory; > > - private static HashMap status = > - new HashMap(); > + private static ConcurrentMap status = > + new ConcurrentHashMap(); > Again, private static synchronized PAV_INIT_STATUS updateStatus(int identifier, PAV_INIT_STATUS newStatus) { calls .get a lot. And while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && wait < maxWait) { try { Thread.sleep(50); wait += 50; } catch (InterruptedException ie) { // just wait } } Again, shouldn't this be a timed wait? Is it correct that it could potentially be testing different applets? > private long handle = 0; > private WindowListener windowEventListener = null; > @@ -401,8 +403,10 @@ > this.identifier = identifier; > this.panel = appletPanel; > > - if (!appletPanels.contains(panel)) > - appletPanels.addElement(panel); > + synchronized(appletPanels) { > + if (!appletPanels.contains(panel)) > + appletPanels.addElement(panel); > + } What is the relative rate of mutations (adding new panels, removing dead ones) like compared to iteration? If we iterate a lot more than we modify the collection, I think a CopyOnWriteArrayList should be considered. Then addIfAbsent can be used here. > > windowEventListener = new WindowAdapter() { > > @@ -656,8 +660,9 @@ > PluginDebug.debug("Attempting to destroy frame ", identifier); > > // Try to dispose the panel right away > - if (applets.containsKey(identifier)) > - applets.get(identifier).dispose(); > + PluginAppletViewer pav = applets.get(identifier); > + if (pav != null) > + pav.dispose(); I agree with this change. I'm worried about the line below: // If panel is already disposed, return if (applets.get(identifier).panel.applet == null) { PluginDebug.debug(identifier, " panel inactive. Returning."); return; } Shouldn't pav be reussed there too? Shouldn't that check be before the dispose call? > > // If panel is already disposed, return > if (applets.get(identifier).panel.applet == null) { > @@ -895,7 +900,7 @@ > imageRefs.clear(); > } > > - static Vector appletPanels = new Vector(); > + private static Vector appletPanels = new Vector(); > > /** > * Get an applet by name. > @@ -904,20 +909,22 @@ > name = name.toLowerCase(); > SocketPermission panelSp = > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > - AppletPanel p = (AppletPanel) e.nextElement(); > - String param = p.getParameter("name"); > - if (param != null) { > - param = param.toLowerCase(); > - } > - if (name.equals(param) && > - p.getDocumentBase().equals(panel.getDocumentBase())) { > + synchronized(appletPanels) { > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > + AppletPanel p = (AppletPanel) e.nextElement(); > + String param = p.getParameter("name"); > + if (param != null) { > + param = param.toLowerCase(); > + } > + if (name.equals(param) && > + p.getDocumentBase().equals(panel.getDocumentBase())) { The cast to AppletPanel is redundant. > > - SocketPermission sp = > + SocketPermission sp = Indentation change. Shouldn't be in this patch. > new SocketPermission(p.getCodeBase().getHost(), "connect"); > > - if (panelSp.implies(sp)) { > - return p.applet; > + if (panelSp.implies(sp)) { > + return p.applet; > + } This looks like just brackets being added. Shouldn't be in this patch. > } > } > } > @@ -933,14 +940,16 @@ > SocketPermission panelSp = > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > - AppletPanel p = e.nextElement(); > - if (p.getDocumentBase().equals(panel.getDocumentBase())) { > + synchronized(appletPanels) { > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > + AppletPanel p = e.nextElement(); > + if (p.getDocumentBase().equals(panel.getDocumentBase())) { > > - SocketPermission sp = > + SocketPermission sp = > new SocketPermission(p.getCodeBase().getHost(), "connect"); > - if (panelSp.implies(sp)) { > - v.addElement(p.applet); > + if (panelSp.implies(sp)) { > + v.addElement(p.applet); > + } > } > } > } I may have missed some stuff here but in that case, it should be clearly documented in the class. To be frank, this class is a mess. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Tue Apr 12 13:20:55 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 12 Apr 2011 16:20:55 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412200947.GL7262@rivendell.middle-earth.co.uk> References: <20110412171054.GA27867@redhat.com> <1729717679.196075.1302636205757.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110412200947.GL7262@rivendell.middle-earth.co.uk> Message-ID: <20110412202055.GE27867@redhat.com> * Dr Andrew John Hughes [2011-04-12 16:09]: > On 15:23 Tue 12 Apr , Denis Lila wrote: > > snip... > > > diff -r 934543b8084d ChangeLog > > --- a/ChangeLog Mon Apr 11 16:03:44 2011 +0100 > > +++ b/ChangeLog Tue Apr 12 11:18:57 2011 -0400 > > @@ -1,3 +1,13 @@ > > +2011-04-12 Denis Lila > > + > > + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > + (applets, status): Make concurrent. > > + (PluginAppletViewer): Synchronize appletPanels addElement. > > + (destroyApplet): Remove applets.containsKey because it and the > > + get that followed it were not atomic. > > + (appletPanels): Privatize. > > + (getApplet, getApplets): Synchronize iteration. > > + > > 2011-04-08 Omair Majid > > > > * README: Update to add notes on rhino and junit. > > diff -r 934543b8084d plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Apr 11 16:03:44 2011 +0100 > > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Tue Apr 12 11:18:57 2011 -0400 > > @@ -103,6 +103,8 @@ > > import java.util.List; > > import java.util.Map; > > import java.util.Vector; > > +import java.util.concurrent.ConcurrentHashMap; > > +import java.util.concurrent.ConcurrentMap; > > > > import javax.swing.SwingUtilities; > > > > @@ -340,15 +342,15 @@ > > new HashMap(); > > > > // Instance identifier -> PluginAppletViewer object. > > - private static HashMap applets = > > - new HashMap(); > > + private static ConcurrentMap applets = > > + new ConcurrentHashMap(); > > > > I don't think this is enough. There are a number of cases where the applets > collection is misused. > > 1. > while (!applets.containsKey(identifier) && // Map is populated only by reFrame > (wait < maxWait)) { > > try { > Thread.sleep(50); > wait += 50; > } catch (InterruptedException ie) { > // just wait > } > } > > Surely this should be a timed wait and additions to applets should be accompanied by > a notifyAll? > > 2. > > PluginAppletViewer oldFrame = applets.get(identifier); > > // We should not try to destroy an applet during > // initialization. It may cause an inconsistent state, > // which would bad if it's a trusted applet that > // read/writes to files > waitForAppletInit((NetxPanel) applets.get(identifier).panel); > > The two get calls could retrieve different values if a put occurs in the interim. > > 3. > > // Wait till initialization finishes > while (!applets.containsKey(identifier) && > ( > !status.containsKey(identifier) || > status.get(identifier).equals(PAV_INIT_STATUS.PRE_INIT) > )) > ; > > Again, this busy loop would be better waiting on a notification that the applet has > been initialised. > > 4. > > // Wait till initialization finishes > while (!applets.containsKey(identifier) && > ( > !status.containsKey(identifier) || > status.get(identifier).equals(PAV_INIT_STATUS.PRE_INIT) > )) > ; > > // don't bother processing further for inactive applets > if (status.get(identifier).equals(PAV_INIT_STATUS.INACTIVE)) > return; > > applets.get(identifier).handleMessage(reference, message); > > Why the multiple get calls? There is the potential for these to return different > values. > > 5. > > final int fIdentifier = identifier; > SwingUtilities.invokeLater(new Runnable() { > public void run() { > applets.get(fIdentifier).appletClose(); > } > }); > > fIndentifier could point to a different applet. Why not just retain a reference to the applet? > > > > private static PluginStreamHandler streamhandler; > > > > private static PluginCallRequestFactory requestFactory; > > > > - private static HashMap status = > > - new HashMap(); > > + private static ConcurrentMap status = > > + new ConcurrentHashMap(); > > > > Again, private static synchronized PAV_INIT_STATUS updateStatus(int identifier, PAV_INIT_STATUS newStatus) { > calls .get a lot. And > > while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && wait < maxWait) { > try { > Thread.sleep(50); > wait += 50; > } catch (InterruptedException ie) { > // just wait > } > } > > Again, shouldn't this be a timed wait? > > Is it correct that it could potentially be testing different applets? > > > private long handle = 0; > > private WindowListener windowEventListener = null; > > @@ -401,8 +403,10 @@ > > this.identifier = identifier; > > this.panel = appletPanel; > > > > - if (!appletPanels.contains(panel)) > > - appletPanels.addElement(panel); > > + synchronized(appletPanels) { > > + if (!appletPanels.contains(panel)) > > + appletPanels.addElement(panel); > > + } > > What is the relative rate of mutations (adding new panels, removing dead ones) > like compared to iteration? If we iterate a lot more than we modify the collection, > I think a CopyOnWriteArrayList should be considered. Then addIfAbsent can be used here. > > > > > windowEventListener = new WindowAdapter() { > > > > @@ -656,8 +660,9 @@ > > PluginDebug.debug("Attempting to destroy frame ", identifier); > > > > // Try to dispose the panel right away > > - if (applets.containsKey(identifier)) > > - applets.get(identifier).dispose(); > > + PluginAppletViewer pav = applets.get(identifier); > > + if (pav != null) > > + pav.dispose(); > > I agree with this change. > > I'm worried about the line below: > > // If panel is already disposed, return > if (applets.get(identifier).panel.applet == null) { > PluginDebug.debug(identifier, " panel inactive. Returning."); > return; > } > > Shouldn't pav be reussed there too? > Shouldn't that check be before the dispose call? > > > > > // If panel is already disposed, return > > if (applets.get(identifier).panel.applet == null) { > > @@ -895,7 +900,7 @@ > > imageRefs.clear(); > > } > > > > - static Vector appletPanels = new Vector(); > > + private static Vector appletPanels = new Vector(); > > > > /** > > * Get an applet by name. > > @@ -904,20 +909,22 @@ > > name = name.toLowerCase(); > > SocketPermission panelSp = > > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > > - AppletPanel p = (AppletPanel) e.nextElement(); > > - String param = p.getParameter("name"); > > - if (param != null) { > > - param = param.toLowerCase(); > > - } > > - if (name.equals(param) && > > - p.getDocumentBase().equals(panel.getDocumentBase())) { > > + synchronized(appletPanels) { > > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > > + AppletPanel p = (AppletPanel) e.nextElement(); > > + String param = p.getParameter("name"); > > + if (param != null) { > > + param = param.toLowerCase(); > > + } > > + if (name.equals(param) && > > + p.getDocumentBase().equals(panel.getDocumentBase())) { > > The cast to AppletPanel is redundant. > > > > > - SocketPermission sp = > > + SocketPermission sp = > > Indentation change. Shouldn't be in this patch. > > > new SocketPermission(p.getCodeBase().getHost(), "connect"); > > > > - if (panelSp.implies(sp)) { > > - return p.applet; > > + if (panelSp.implies(sp)) { > > + return p.applet; > > + } > > This looks like just brackets being added. Shouldn't be in this patch. > > > } > > } > > } > > @@ -933,14 +940,16 @@ > > SocketPermission panelSp = > > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > > > > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > > - AppletPanel p = e.nextElement(); > > - if (p.getDocumentBase().equals(panel.getDocumentBase())) { > > + synchronized(appletPanels) { > > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > > + AppletPanel p = e.nextElement(); > > + if (p.getDocumentBase().equals(panel.getDocumentBase())) { > > > > - SocketPermission sp = > > + SocketPermission sp = > > new SocketPermission(p.getCodeBase().getHost(), "connect"); > > - if (panelSp.implies(sp)) { > > - v.addElement(p.applet); > > + if (panelSp.implies(sp)) { > > + v.addElement(p.applet); > > + } > > } > > } > > } > > > I may have missed some stuff here but in that case, it should be clearly documented in the class. > To be frank, this class is a mess. Amen to that. It has been carried on since the old plugin. I will be rewriting significant chunks of it with the security rewrite, as members and access levels will all be re-evaluated. /me can't wait for this and JNLPClassLoader to be cleaned up. Cheers, Deepak > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Apr 12 13:20:49 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Tue, 12 Apr 2011 21:20:49 +0100 Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <1480987931.188008.1302627021361.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110408002826.GE32676@rivendell.middle-earth.co.uk> <1480987931.188008.1302627021361.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110412202049.GM7262@rivendell.middle-earth.co.uk> On 12:50 Tue 12 Apr , Denis Lila wrote: > Hi Andrew. > > I'm sorry it took so long to answer this. I've been busy > with a few other things. > > > No, this isn't enough. This piece of code: > > > > private URL findBestUrl(Resource resource) { > > 1. DownloadOptions options = downloadOptions.get(resource); > > 2. if (options == null) { > > 3. options = new DownloadOptions(false, false); > > } > > > > may be subject to a race from addResource. Line 1 may retrieve null, > > but that thread may then be interrupted before line 2 can be executed. > > In the meantime, the resource could be added to downloadOptions and > > this thread would still have the old stale value. > > I don't think this is a problem findBestUrl never races with addResource. > It's only called from initializeResource, which isn't called unless > the resource has been already added. > That may be true now, but future code could break this implicit assumption without realising it. It also wasn't that obvious to me as the code stands now. > > It's also odd code in that this new instance is created but not stored > > in the map. So it seems possible that many threads could call this > > method, all get a return value of null and create new instances of > > DownloadOptions. The control flow in this class is not very clear, > > but I presume the null check means that there is a possibility that > > this method can be called before the resource is added in addResource. > > > > I would suggest replacing those three lines with: > > > > DownloadOptions options = downloadOptions.putIfAbsent(resource, new > > DownloadOptions(false,false)); > > I agree that it's odd, but this code has deadlocks in it and it's far > more complex than necessary so a lot of it will be re-written. I would > like to wait until that happens before pushing something like your > suggestion, because it is likely to become unecessary. > Hmmm, you're the one who wanted to change it in the first place... > Regards, > Denis. > > ----- Original Message ----- > > On 12:13 Tue 05 Apr , Denis Lila wrote: > > > Hi. > > > > > > I think I found a concurrency problem in > > > ResourceTracker.addResource. This method is not static. > > > It is called from different threads, and it writes to > > > downloadOptions which is a static HashMap. This is not > > > safe. The patch uses a ConcurrentHashMap. That should > > > be enough to fix it. > > > > > > Ok to push? > > > > > > Regards, > > > Denis. > > > > > > > > > This ensures, atomically, that any existing value is retrieved and > > stored > > in options, but if one is not present, the default is added and > > returned. > > With addResource using put instead of putIfAbsent, it should still > > override > > a default added by this method. > > > > This also means there's a reason to follow Andrew's suggestion, as > > putIfAbsent is unique to ConcurrentHashMap. In general, the interface > > type (Map) should be used rather than the specific type to allow easy > > transition between different implementations. It prevents code using > > implementation-specific methods which would make later implementation > > changes harder e.g. if this class had been using HashMap directly, it > > may have relied on HashMap-only methods. > > > > > diff -r 62011060e7ea ChangeLog > > > --- a/ChangeLog Tue Apr 05 12:07:10 2011 -0400 > > > +++ b/ChangeLog Tue Apr 05 12:12:33 2011 -0400 > ... -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at redhat.com Tue Apr 12 13:25:58 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 16:25:58 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412200159.GD27867@redhat.com> Message-ID: <1567612367.197375.1302639958351.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Perhaps I should have clarified a it more -- I couldn't come up with > negative consequences in *our* case as we use integer keys which hash > to > themselves, so there would never be any lower level buckets to worry > about. > > So essentially we are using HashMap as an indexed list where an index > will have only one element and it is never clobbered. It's true that all the hashes will be different, but just because two keys have different hashes does not mean that they will go in different chains, so the example I gave is still possible, even in our case. > That said, your point about making an assumption about the internal > implementation is a valid concern. Though we are safe now, there is no > guarantee of it in the future. Nice! So, can I push it? ----- Original Message ----- > * Denis Lila [2011-04-12 14:54]: > > > You have discarded the check for panel == null. Why? > > > > Because it's a local variable. If it's null, that's an > > infinite loop. Also, if it's null, it can't get > > there anyway, because an NPE would be thrown a few lines > > prior. > > > > Ah okay, seems like that code was copied and pasted from elsewhere. > The > panel == null check occurs in multiple places. > > > > It is unsafe to read only if we iterate over it, which we don't. > > > ConcurrentHapMap does not lock when retrieving either. From the > > > JavaDocs: > > > > > > "However, even though all operations are thread-safe, retrieval > > > operations do not entail locking ..." > > > > > > So status is ok. > > > > > As mentioned above, status is OK as a HashMap. I think rather than > > > making applets a ConcurrentMap, write to it should be synchronized > > > instead. The map is written to only in one location, and it > > > happens > > > only > > > once per applet init, so race for it will be rare. OTOH, we read > > > it in > > > many places, and since ConcurrentHashMap does not guarantee > > > non-blocking > > > read in perpetuity, I think we should avoid it. > > > > I don't think status is ok, and I don't think synchronizing only the > > writes to applets is right. The docs for HashMap say "If multiple > > threads access a hash map concurrently, and at least one of the > > threads modifies the map structurally, it must be synchronized > > externally". We satisfy these requirements so we must use a > > ConcurrentHashMap (or do our own locking). The reason for this is > > that HashMap was not build with concurrent access in mind and it's > > not safe for "get" to be traversing the internal data structures > > of the map while some other thread is modifying these data > > structures. > > > > For example: > > suppose a map is implemented by chaining, and suppose we have a > > concurrent get(x) and remove(y) in progress. Suppose also that > > x.hashCode()==y.hashCode(), so they're in the same chain, and that > > x is after y in the chain. y is removed from the chain with a > > sequence of operations like this: > > p = y.prev > > n = y.next > > p.next = n > > n.prev = p > > y.prev = null > > y.next = null > > > > Now, the chain traversal in get(x) could get to p when p.next == y, > > so then it goes to y, but then y.next=null could execute, and get(x) > > will think that the end of the chain has been reached and it will > > wrongly return null. > > > > > > > > > Deepak From dlila at redhat.com Tue Apr 12 13:49:36 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 16:49:36 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412200947.GL7262@rivendell.middle-earth.co.uk> Message-ID: <585433630.197789.1302641376341.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > while (!applets.containsKey(identifier) && // Map is populated only by > reFrame > (wait < maxWait)) { > > try { > Thread.sleep(50); > wait += 50; > } catch (InterruptedException ie) { > // just wait > } > } > > Surely this should be a timed wait and additions to applets should be > accompanied by > a notifyAll? That's what I thought when I first saw this code. But this works, and I see no practical reason to change it. If you really think we should, I could do it, but it should be it's own changeset. > PluginAppletViewer oldFrame = applets.get(identifier); > > // We should not try to destroy an applet during > // initialization. It may cause an inconsistent state, > // which would bad if it's a trusted applet that > // read/writes to files > waitForAppletInit((NetxPanel) applets.get(identifier).panel); > > The two get calls could retrieve different values if a put occurs in > the interim. Yes, but it doesn't matter. oldFrame is dead code. > The cast to AppletPanel is redundant. The enumeration is not using generics, so we need the cast. > Indentation change. Shouldn't be in this patch. ...... > This looks like just brackets being added. Shouldn't be in this patch. The indentation changed because the code was wrapped in a synchronized block. Not putting it in this patch would be breaking style conventions. > To be frank, this class is a mess. I couldn't agree more. And it's not just this class. It's almost every class in the icedtea-web sun.applet package. As for the points you made that I didn't reply to: None of them were pointing out any mistakes in my patch, so can I push this patch, and address some of them (in particular the comments on destroyApplet) in my second patch (the refactoring one)? Thank you, Denis. ----- Original Message ----- > On 15:23 Tue 12 Apr , Denis Lila wrote: > > snip... > > snip... From dbhole at redhat.com Tue Apr 12 14:06:37 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 12 Apr 2011 17:06:37 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1567612367.197375.1302639958351.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110412200159.GD27867@redhat.com> <1567612367.197375.1302639958351.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110412210636.GG27867@redhat.com> * Denis Lila [2011-04-12 16:25]: > > Perhaps I should have clarified a it more -- I couldn't come up with > > negative consequences in *our* case as we use integer keys which hash > > to > > themselves, so there would never be any lower level buckets to worry > > about. > > > > So essentially we are using HashMap as an indexed list where an index > > will have only one element and it is never clobbered. > > It's true that all the hashes will be different, but just > because two keys have different hashes does not mean that > they will go in different chains, so the example I gave > is still possible, even in our case. > > > That said, your point about making an assumption about the internal > > implementation is a valid concern. Though we are safe now, there is no > > guarantee of it in the future. > > Nice! So, can I push it? > Andrew posted some valid concerns in another thread. After those are all resolved, OK from me. Cheers, Deepak > ----- Original Message ----- > > * Denis Lila [2011-04-12 14:54]: > > > > You have discarded the check for panel == null. Why? > > > > > > Because it's a local variable. If it's null, that's an > > > infinite loop. Also, if it's null, it can't get > > > there anyway, because an NPE would be thrown a few lines > > > prior. > > > > > > > Ah okay, seems like that code was copied and pasted from elsewhere. > > The > > panel == null check occurs in multiple places. > > > > > > It is unsafe to read only if we iterate over it, which we don't. > > > > ConcurrentHapMap does not lock when retrieving either. From the > > > > JavaDocs: > > > > > > > > "However, even though all operations are thread-safe, retrieval > > > > operations do not entail locking ..." > > > > > > > > So status is ok. > > > > > > > As mentioned above, status is OK as a HashMap. I think rather than > > > > making applets a ConcurrentMap, write to it should be synchronized > > > > instead. The map is written to only in one location, and it > > > > happens > > > > only > > > > once per applet init, so race for it will be rare. OTOH, we read > > > > it in > > > > many places, and since ConcurrentHashMap does not guarantee > > > > non-blocking > > > > read in perpetuity, I think we should avoid it. > > > > > > I don't think status is ok, and I don't think synchronizing only the > > > writes to applets is right. The docs for HashMap say "If multiple > > > threads access a hash map concurrently, and at least one of the > > > threads modifies the map structurally, it must be synchronized > > > externally". We satisfy these requirements so we must use a > > > ConcurrentHashMap (or do our own locking). The reason for this is > > > that HashMap was not build with concurrent access in mind and it's > > > not safe for "get" to be traversing the internal data structures > > > of the map while some other thread is modifying these data > > > structures. > > > > > > For example: > > > suppose a map is implemented by chaining, and suppose we have a > > > concurrent get(x) and remove(y) in progress. Suppose also that > > > x.hashCode()==y.hashCode(), so they're in the same chain, and that > > > x is after y in the chain. y is removed from the chain with a > > > sequence of operations like this: > > > p = y.prev > > > n = y.next > > > p.next = n > > > n.prev = p > > > y.prev = null > > > y.next = null > > > > > > Now, the chain traversal in get(x) could get to p when p.next == y, > > > so then it goes to y, but then y.next=null could execute, and get(x) > > > will think that the end of the chain has been reached and it will > > > wrongly return null. > > > > > > > > > > > > > > > > > > > Deepak From dlila at redhat.com Tue Apr 12 14:24:08 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 12 Apr 2011 17:24:08 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412210636.GG27867@redhat.com> Message-ID: <1178490457.198378.1302643448929.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Andrew posted some valid concerns in another thread. After those are > all resolved, OK from me. I replied to that e-mail. Some of those were invalid and I pointed those out. The others I think were good points but they weren't directly related to this patch, so I think they should be fixed in a future changeset. The changes to destroyApplet are directly related to this, but I would rather put them in the attached refactoring patch because there's nothing wrong with any of the changes in this patch and if I put them in this patch, I'll have to remake the refactoring patch and that will not be an efficient use of time. Thank you, Denis. ----- Original Message ----- > * Denis Lila [2011-04-12 16:25]: > > > Perhaps I should have clarified a it more -- I couldn't come up > > > with > > > negative consequences in *our* case as we use integer keys which > > > hash > > > to > > > themselves, so there would never be any lower level buckets to > > > worry > > > about. > > > > > > So essentially we are using HashMap as an indexed list where an > > > index > > > will have only one element and it is never clobbered. > > > > It's true that all the hashes will be different, but just > > because two keys have different hashes does not mean that > > they will go in different chains, so the example I gave > > is still possible, even in our case. > > > > > That said, your point about making an assumption about the > > > internal > > > implementation is a valid concern. Though we are safe now, there > > > is no > > > guarantee of it in the future. > > > > Nice! So, can I push it? > > > > > Cheers, > Deepak > > > ----- Original Message ----- > > > * Denis Lila [2011-04-12 14:54]: > > > > > You have discarded the check for panel == null. Why? > > > > > > > > Because it's a local variable. If it's null, that's an > > > > infinite loop. Also, if it's null, it can't get > > > > there anyway, because an NPE would be thrown a few lines > > > > prior. > > > > > > > > > > Ah okay, seems like that code was copied and pasted from > > > elsewhere. > > > The > > > panel == null check occurs in multiple places. > > > > > > > > It is unsafe to read only if we iterate over it, which we > > > > > don't. > > > > > ConcurrentHapMap does not lock when retrieving either. From > > > > > the > > > > > JavaDocs: > > > > > > > > > > "However, even though all operations are thread-safe, > > > > > retrieval > > > > > operations do not entail locking ..." > > > > > > > > > > So status is ok. > > > > > > > > > As mentioned above, status is OK as a HashMap. I think rather > > > > > than > > > > > making applets a ConcurrentMap, write to it should be > > > > > synchronized > > > > > instead. The map is written to only in one location, and it > > > > > happens > > > > > only > > > > > once per applet init, so race for it will be rare. OTOH, we > > > > > read > > > > > it in > > > > > many places, and since ConcurrentHashMap does not guarantee > > > > > non-blocking > > > > > read in perpetuity, I think we should avoid it. > > > > > > > > I don't think status is ok, and I don't think synchronizing only > > > > the > > > > writes to applets is right. The docs for HashMap say "If > > > > multiple > > > > threads access a hash map concurrently, and at least one of the > > > > threads modifies the map structurally, it must be synchronized > > > > externally". We satisfy these requirements so we must use a > > > > ConcurrentHashMap (or do our own locking). The reason for this > > > > is > > > > that HashMap was not build with concurrent access in mind and > > > > it's > > > > not safe for "get" to be traversing the internal data structures > > > > of the map while some other thread is modifying these data > > > > structures. > > > > > > > > For example: > > > > suppose a map is implemented by chaining, and suppose we have a > > > > concurrent get(x) and remove(y) in progress. Suppose also that > > > > x.hashCode()==y.hashCode(), so they're in the same chain, and > > > > that > > > > x is after y in the chain. y is removed from the chain with a > > > > sequence of operations like this: > > > > p = y.prev > > > > n = y.next > > > > p.next = n > > > > n.prev = p > > > > y.prev = null > > > > y.next = null > > > > > > > > Now, the chain traversal in get(x) could get to p when p.next == > > > > y, > > > > so then it goes to y, but then y.next=null could execute, and > > > > get(x) > > > > will think that the end of the chain has been reached and it > > > > will > > > > wrongly return null. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Deepak -------------- next part -------------- A non-text attachment was scrubbed... Name: RefactorPAV.patch Type: text/x-patch Size: 12330 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110412/e78fe5a8/RefactorPAV.patch From dbhole at redhat.com Tue Apr 12 14:40:16 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 12 Apr 2011 17:40:16 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1178490457.198378.1302643448929.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110412210636.GG27867@redhat.com> <1178490457.198378.1302643448929.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110412214015.GH27867@redhat.com> * Denis Lila [2011-04-12 17:24]: > > Andrew posted some valid concerns in another thread. After those are > > all resolved, OK from me. > > I replied to that e-mail. Some of those were invalid > and I pointed those out. The others I think were good > points but they weren't directly related to this patch, > so I think they should be fixed in a future changeset. > > The changes to destroyApplet are directly related to > this, but I would rather put them in the attached > refactoring patch because there's nothing wrong with > any of the changes in this patch and if I put them in this > patch, I'll have to remake the refactoring patch and > that will not be an efficient use of time. > Did you change any functionality in destroyApplet or is it just spacing/style fixes? Deepak > Thank you, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-12 16:25]: > > > > Perhaps I should have clarified a it more -- I couldn't come up > > > > with > > > > negative consequences in *our* case as we use integer keys which > > > > hash > > > > to > > > > themselves, so there would never be any lower level buckets to > > > > worry > > > > about. > > > > > > > > So essentially we are using HashMap as an indexed list where an > > > > index > > > > will have only one element and it is never clobbered. > > > > > > It's true that all the hashes will be different, but just > > > because two keys have different hashes does not mean that > > > they will go in different chains, so the example I gave > > > is still possible, even in our case. > > > > > > > That said, your point about making an assumption about the > > > > internal > > > > implementation is a valid concern. Though we are safe now, there > > > > is no > > > > guarantee of it in the future. > > > > > > Nice! So, can I push it? > > > > > > > > > > Cheers, > > Deepak > > > > > ----- Original Message ----- > > > > * Denis Lila [2011-04-12 14:54]: > > > > > > You have discarded the check for panel == null. Why? > > > > > > > > > > Because it's a local variable. If it's null, that's an > > > > > infinite loop. Also, if it's null, it can't get > > > > > there anyway, because an NPE would be thrown a few lines > > > > > prior. > > > > > > > > > > > > > Ah okay, seems like that code was copied and pasted from > > > > elsewhere. > > > > The > > > > panel == null check occurs in multiple places. > > > > > > > > > > It is unsafe to read only if we iterate over it, which we > > > > > > don't. > > > > > > ConcurrentHapMap does not lock when retrieving either. From > > > > > > the > > > > > > JavaDocs: > > > > > > > > > > > > "However, even though all operations are thread-safe, > > > > > > retrieval > > > > > > operations do not entail locking ..." > > > > > > > > > > > > So status is ok. > > > > > > > > > > > As mentioned above, status is OK as a HashMap. I think rather > > > > > > than > > > > > > making applets a ConcurrentMap, write to it should be > > > > > > synchronized > > > > > > instead. The map is written to only in one location, and it > > > > > > happens > > > > > > only > > > > > > once per applet init, so race for it will be rare. OTOH, we > > > > > > read > > > > > > it in > > > > > > many places, and since ConcurrentHashMap does not guarantee > > > > > > non-blocking > > > > > > read in perpetuity, I think we should avoid it. > > > > > > > > > > I don't think status is ok, and I don't think synchronizing only > > > > > the > > > > > writes to applets is right. The docs for HashMap say "If > > > > > multiple > > > > > threads access a hash map concurrently, and at least one of the > > > > > threads modifies the map structurally, it must be synchronized > > > > > externally". We satisfy these requirements so we must use a > > > > > ConcurrentHashMap (or do our own locking). The reason for this > > > > > is > > > > > that HashMap was not build with concurrent access in mind and > > > > > it's > > > > > not safe for "get" to be traversing the internal data structures > > > > > of the map while some other thread is modifying these data > > > > > structures. > > > > > > > > > > For example: > > > > > suppose a map is implemented by chaining, and suppose we have a > > > > > concurrent get(x) and remove(y) in progress. Suppose also that > > > > > x.hashCode()==y.hashCode(), so they're in the same chain, and > > > > > that > > > > > x is after y in the chain. y is removed from the chain with a > > > > > sequence of operations like this: > > > > > p = y.prev > > > > > n = y.next > > > > > p.next = n > > > > > n.prev = p > > > > > y.prev = null > > > > > y.next = null > > > > > > > > > > Now, the chain traversal in get(x) could get to p when p.next == > > > > > y, > > > > > so then it goes to y, but then y.next=null could execute, and > > > > > get(x) > > > > > will think that the end of the chain has been reached and it > > > > > will > > > > > wrongly return null. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Deepak > diff -r 7f589f802faf ChangeLog > --- a/ChangeLog Tue Apr 12 11:27:53 2011 -0400 > +++ b/ChangeLog Tue Apr 12 12:14:32 2011 -0400 > @@ -1,3 +1,17 @@ > +2011-04-12 Denis Lila > + > + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > + Remove unused imports, added various SuppressWarnings annotations. > + (createPanel): Return NetxPanel from doPriviledged. Remove dead code. > + (PluginParseRequest): Remove - unused. > + (defaultSaveFile, label, statusMsgStream, requests, handle): Remove - unused. > + (identifier, appletPanels): Privatize. > + (applets, status): Use ConcurrentHashMaps. > + (framePanel, PluginAppletViewer): Remove unused PrintStream argument. > + (forceredraw): Remove - unused. > + (getApplets): Use generics. > + (appletClose): Fix style to match our convention. > + > 2011-04-12 Denis Lila > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > diff -r 7f589f802faf plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Tue Apr 12 11:27:53 2011 -0400 > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Tue Apr 12 12:14:32 2011 -0400 > @@ -70,23 +70,19 @@ > import java.awt.Graphics; > import java.awt.Image; > import java.awt.Insets; > -import java.awt.Label; > import java.awt.Toolkit; > import java.awt.event.WindowAdapter; > import java.awt.event.WindowEvent; > import java.awt.event.WindowListener; > import java.awt.print.PageFormat; > import java.awt.print.Printable; > -import java.io.BufferedReader; > import java.io.IOException; > import java.io.InputStream; > -import java.io.InputStreamReader; > import java.io.PrintStream; > import java.io.Reader; > import java.io.StringReader; > import java.io.UnsupportedEncodingException; > import java.lang.reflect.InvocationTargetException; > -import java.net.MalformedURLException; > import java.net.SocketPermission; > import java.net.URI; > import java.net.URL; > @@ -128,49 +124,27 @@ > long handle, int x, int y, > final URL doc, > final Hashtable atts) { > - AppletViewerPanel panel = AccessController.doPrivileged(new PrivilegedAction() { > - public AppletViewerPanel run() { > - try { > - AppletViewerPanel panel = new NetxPanel(doc, atts, false); > - AppletViewerPanel.debug("Using NetX panel"); > - PluginDebug.debug(atts.toString()); > - return panel; > - } catch (Exception ex) { > - AppletViewerPanel.debug("Unable to start NetX applet - defaulting to Sun applet", ex); > - return new AppletViewerPanel(doc, atts); > - } > + NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { > + public NetxPanel run() { > + NetxPanel panel = new NetxPanel(doc, atts, false); > + NetxPanel.debug("Using NetX panel"); > + PluginDebug.debug(atts.toString()); > + return panel; > } > }); > > // create the frame. > - PluginAppletViewer.framePanel(identifier, System.out, handle, panel); > + PluginAppletViewer.framePanel(identifier, handle, panel); > > panel.init(); > > // Start the applet > initEventQueue(panel); > > - // Applet initialized. Find out it's classloader and add it to the list > - String portComponent = doc.getPort() != -1 ? ":" + doc.getPort() : ""; > - String codeBase = doc.getProtocol() + "://" + doc.getHost() + portComponent; > - > - if (atts.get("codebase") != null) { > - try { > - URL appletSrcURL = new URL(codeBase + atts.get("codebase")); > - codeBase = appletSrcURL.getProtocol() + "://" + appletSrcURL.getHost(); > - } catch (MalformedURLException mfue) { > - // do nothing > - } > - } > - > - // Wait for the panel to initialize > - // (happens in a separate thread) > - Applet a; > - > // Wait for panel to come alive > int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > int wait = 0; > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait < maxWait)) { > + while (!panel.isAlive() && wait < maxWait) { > try { > Thread.sleep(50); > wait += 50; > @@ -183,10 +157,10 @@ > // (happens in a separate thread) > PluginAppletViewer.waitForAppletInit((NetxPanel) panel); > > - a = panel.getApplet(); > + Applet a = panel.getApplet(); > > // Still null? > - if (panel.getApplet() == null) { > + if (a == null) { > streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > return null; > } > @@ -194,8 +168,8 @@ > PluginDebug.debug("Applet ", a.getClass(), " initialized"); > streamhandler.write("instance " + identifier + " reference 0 initialized"); > > - AppletSecurityContextManager.getSecurityContext(0).associateSrc(((NetxPanel) panel).getAppletClassLoader(), doc); > - AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, ((NetxPanel) panel).getAppletClassLoader()); > + AppletSecurityContextManager.getSecurityContext(0).associateSrc(panel.getAppletClassLoader(), doc); > + AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, panel.getAppletClassLoader()); > > return panel; > } > @@ -291,21 +265,12 @@ > } > } > > -class PluginParseRequest { > - long handle; > - String tag; > - String documentbase; > -} > - > /* > */ > // FIXME: declare JSProxy implementation > + at SuppressWarnings("serial") > public class PluginAppletViewer extends XEmbeddedFrame > implements AppletContext, Printable { > - /** > - * Some constants... > - */ > - private static String defaultSaveFile = "Applet.ser"; > > /** > * Enumerates the current status of an applet > @@ -323,23 +288,9 @@ > /** > * The panel in which the applet is being displayed. > */ > - AppletViewerPanel panel; > + private AppletViewerPanel panel; > > - /** > - * The status line. > - */ > - Label label; > - > - /** > - * output status messages to this stream > - */ > - > - PrintStream statusMsgStream; > - > - int identifier; > - > - private static HashMap requests = > - new HashMap(); > + private int identifier; > > // Instance identifier -> PluginAppletViewer object. > private static ConcurrentMap applets = > @@ -352,7 +303,6 @@ > private static ConcurrentMap status = > new ConcurrentHashMap(); > > - private long handle = 0; > private WindowListener windowEventListener = null; > private AppletEventListener appletEventListener = null; > > @@ -370,15 +320,14 @@ > public PluginAppletViewer() { > } > > - public static void framePanel(int identifier, PrintStream statusMsgStream, > - long handle, AppletViewerPanel panel) { > + public static void framePanel(int identifier, long handle, NetxPanel panel) { > > PluginDebug.debug("Framing ", panel); > > // SecurityManager MUST be set, and only privileged code may call reFrame() > System.getSecurityManager().checkPermission(new AllPermission()); > > - PluginAppletViewer appletFrame = new PluginAppletViewer(handle, identifier, statusMsgStream, panel); > + PluginAppletViewer appletFrame = new PluginAppletViewer(handle, identifier, panel); > > appletFrame.add("Center", panel); > appletFrame.pack(); > @@ -395,11 +344,9 @@ > * Create new plugin appletviewer frame > */ > private PluginAppletViewer(long handle, final int identifier, > - PrintStream statusMsgStream, > - AppletViewerPanel appletPanel) { > + NetxPanel appletPanel) { > > super(handle, true); > - this.statusMsgStream = statusMsgStream; > this.identifier = identifier; > this.panel = appletPanel; > > @@ -547,8 +494,6 @@ > if (wait >= maxWait) > throw new Exception("Applet initialization timeout"); > > - PluginAppletViewer oldFrame = applets.get(identifier); > - > // We should not try to destroy an applet during > // initialization. It may cause an inconsistent state, > // which would bad if it's a trusted applet that > @@ -792,7 +737,7 @@ > > // Still null? > if (panel.getApplet() == null) { > - this.streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > + streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > return; > } > > @@ -807,11 +752,6 @@ > } > } > > - // FIXME: Kind of hackish way to ensure synchronized re-drawing > - private synchronized void forceredraw() { > - doLayout(); > - } > - > /* > * Methods for java.applet.AppletContext > */ > @@ -910,8 +850,8 @@ > SocketPermission panelSp = > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > synchronized(appletPanels) { > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > - AppletPanel p = (AppletPanel) e.nextElement(); > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > + AppletPanel p = e.nextElement(); > String param = p.getParameter("name"); > if (param != null) { > param = param.toLowerCase(); > @@ -1652,34 +1592,32 @@ > // > final AppletPanel p = panel; > > - new Thread(new Runnable() > - { > - public void run() > - { > - ClassLoader cl = p.applet.getClass().getClassLoader(); > - > - // Since we want to deal with JNLPClassLoader, extract it if this > - // is a codebase loader > - if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > - cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); > + new Thread(new Runnable() { > + @SuppressWarnings("deprecation") > + public void run() { > + ClassLoader cl = p.applet.getClass().getClassLoader(); > > - ThreadGroup tg = ((JNLPClassLoader) cl).getApplication().getThreadGroup(); > + // Since we want to deal with JNLPClassLoader, extract it if this > + // is a codebase loader > + if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > + cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); > > - appletShutdown(p); > - appletPanels.removeElement(p); > - dispose(); > + ThreadGroup tg = ((JNLPClassLoader) cl).getApplication().getThreadGroup(); > > - if (tg.activeCount() > 0) > - tg.stop(); > + appletShutdown(p); > + appletPanels.removeElement(p); > + dispose(); > > - if (countApplets() == 0) { > - appletSystemExit(); > - } > + if (tg.activeCount() > 0) > + tg.stop(); > > - updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); > - } > - }).start(); > + if (countApplets() == 0) { > + appletSystemExit(); > + } > > + updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); > + } > + }).start(); > } > > /** > @@ -1868,6 +1806,7 @@ > }); > } > > + @SuppressWarnings("unused") > public static void parse(int identifier, long handle, String width, > String height, Reader in, URL url, > PrintStream statusMsgStream, From ahughes at redhat.com Tue Apr 12 16:07:33 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 13 Apr 2011 00:07:33 +0100 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <585433630.197789.1302641376341.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110412200947.GL7262@rivendell.middle-earth.co.uk> <585433630.197789.1302641376341.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110412230733.GP7262@rivendell.middle-earth.co.uk> On 16:49 Tue 12 Apr , Denis Lila wrote: > > while (!applets.containsKey(identifier) && // Map is populated only by > > reFrame > > (wait < maxWait)) { > > > > try { > > Thread.sleep(50); > > wait += 50; > > } catch (InterruptedException ie) { > > // just wait > > } > > } > > > > Surely this should be a timed wait and additions to applets should be > > accompanied by > > a notifyAll? > > That's what I thought when I first saw this code. But this works, and I > see no practical reason to change it. If you really think we should, I > could do it, but it should be it's own changeset. > I'm not saying it should be in the same changeset. I was enumerating problems that still exist with these collections to counter your claim that switching to CHMs will suddenly fix everything. It won't. The practical difference is this code will wake the thread every fifty milliseconds and reading from the map. Using notifyAll would only wake waiting threads when the map has changed. > > PluginAppletViewer oldFrame = applets.get(identifier); > > > > // We should not try to destroy an applet during > > // initialization. It may cause an inconsistent state, > > // which would bad if it's a trusted applet that > > // read/writes to files > > waitForAppletInit((NetxPanel) applets.get(identifier).panel); > > > > The two get calls could retrieve different values if a put occurs in > > the interim. > > Yes, but it doesn't matter. oldFrame is dead code. > Then it needs ripping out so it doesn't confuse people. > > The cast to AppletPanel is redundant. > > The enumeration is not using generics, so we need the cast. > Ok, so the enumeration needs fixing too. Is your other patch handling all this generification? I thought we'd caught most of them. > > > Indentation change. Shouldn't be in this patch. > ...... > > This looks like just brackets being added. Shouldn't be in this patch. > > The indentation changed because the code was wrapped in > a synchronized block. Not putting it in this patch would be > breaking style conventions. > Ok. Please don't remove code from the mail which is being discussed. It was difficult to verify this again here because you removed the code. > > To be frank, this class is a mess. > > I couldn't agree more. > And it's not just this class. It's almost every class in the > icedtea-web sun.applet package. > > As for the points you made that I didn't reply to: > None of them were pointing out any mistakes in my patch, No, they were pointing out mistakes in your assumptions that a switch to CHMs is a fix-all. It's a start, that's all, but I'd prefer everything was fixed. > so can I push this patch, Yes. > and address some of them > (in particular the comments on destroyApplet) in my second > patch (the refactoring one)? > Don't mix them up with other changes. Separate patches please. > Thank you, > Denis. > > ----- Original Message ----- > > On 15:23 Tue 12 Apr , Denis Lila wrote: > > > > snip... > > > > > snip... -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Apr 12 16:10:12 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 13 Apr 2011 00:10:12 +0100 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412214015.GH27867@redhat.com> References: <20110412210636.GG27867@redhat.com> <1178490457.198378.1302643448929.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110412214015.GH27867@redhat.com> Message-ID: <20110412231012.GQ7262@rivendell.middle-earth.co.uk> On 17:40 Tue 12 Apr , Deepak Bhole wrote: > * Denis Lila [2011-04-12 17:24]: > > > Andrew posted some valid concerns in another thread. After those are > > > all resolved, OK from me. > > > > I replied to that e-mail. Some of those were invalid > > and I pointed those out. The others I think were good > > points but they weren't directly related to this patch, > > so I think they should be fixed in a future changeset. > > > > The changes to destroyApplet are directly related to > > this, but I would rather put them in the attached > > refactoring patch because there's nothing wrong with > > any of the changes in this patch and if I put them in this > > patch, I'll have to remake the refactoring patch and > > that will not be an efficient use of time. > > > > Did you change any functionality in destroyApplet or is it just > spacing/style fixes? > As Deepak is infering here; please don't mix those two in one patch. If a patch akin to http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f goes in, I will not be responsible for my actions. > Deepak > > > Thank you, > > Denis. > > > > ----- Original Message ----- > > > * Denis Lila [2011-04-12 16:25]: > > > > > Perhaps I should have clarified a it more -- I couldn't come up > > > > > with > > > > > negative consequences in *our* case as we use integer keys which > > > > > hash > > > > > to > > > > > themselves, so there would never be any lower level buckets to > > > > > worry > > > > > about. > > > > > > > > > > So essentially we are using HashMap as an indexed list where an > > > > > index > > > > > will have only one element and it is never clobbered. > > > > > > > > It's true that all the hashes will be different, but just > > > > because two keys have different hashes does not mean that > > > > they will go in different chains, so the example I gave > > > > is still possible, even in our case. > > > > > > > > > That said, your point about making an assumption about the > > > > > internal > > > > > implementation is a valid concern. Though we are safe now, there > > > > > is no > > > > > guarantee of it in the future. > > > > > > > > Nice! So, can I push it? > > > > > > > > > > > > > > > Cheers, > > > Deepak > > > > > > > ----- Original Message ----- > > > > > * Denis Lila [2011-04-12 14:54]: > > > > > > > You have discarded the check for panel == null. Why? > > > > > > > > > > > > Because it's a local variable. If it's null, that's an > > > > > > infinite loop. Also, if it's null, it can't get > > > > > > there anyway, because an NPE would be thrown a few lines > > > > > > prior. > > > > > > > > > > > > > > > > Ah okay, seems like that code was copied and pasted from > > > > > elsewhere. > > > > > The > > > > > panel == null check occurs in multiple places. > > > > > > > > > > > > It is unsafe to read only if we iterate over it, which we > > > > > > > don't. > > > > > > > ConcurrentHapMap does not lock when retrieving either. From > > > > > > > the > > > > > > > JavaDocs: > > > > > > > > > > > > > > "However, even though all operations are thread-safe, > > > > > > > retrieval > > > > > > > operations do not entail locking ..." > > > > > > > > > > > > > > So status is ok. > > > > > > > > > > > > > As mentioned above, status is OK as a HashMap. I think rather > > > > > > > than > > > > > > > making applets a ConcurrentMap, write to it should be > > > > > > > synchronized > > > > > > > instead. The map is written to only in one location, and it > > > > > > > happens > > > > > > > only > > > > > > > once per applet init, so race for it will be rare. OTOH, we > > > > > > > read > > > > > > > it in > > > > > > > many places, and since ConcurrentHashMap does not guarantee > > > > > > > non-blocking > > > > > > > read in perpetuity, I think we should avoid it. > > > > > > > > > > > > I don't think status is ok, and I don't think synchronizing only > > > > > > the > > > > > > writes to applets is right. The docs for HashMap say "If > > > > > > multiple > > > > > > threads access a hash map concurrently, and at least one of the > > > > > > threads modifies the map structurally, it must be synchronized > > > > > > externally". We satisfy these requirements so we must use a > > > > > > ConcurrentHashMap (or do our own locking). The reason for this > > > > > > is > > > > > > that HashMap was not build with concurrent access in mind and > > > > > > it's > > > > > > not safe for "get" to be traversing the internal data structures > > > > > > of the map while some other thread is modifying these data > > > > > > structures. > > > > > > > > > > > > For example: > > > > > > suppose a map is implemented by chaining, and suppose we have a > > > > > > concurrent get(x) and remove(y) in progress. Suppose also that > > > > > > x.hashCode()==y.hashCode(), so they're in the same chain, and > > > > > > that > > > > > > x is after y in the chain. y is removed from the chain with a > > > > > > sequence of operations like this: > > > > > > p = y.prev > > > > > > n = y.next > > > > > > p.next = n > > > > > > n.prev = p > > > > > > y.prev = null > > > > > > y.next = null > > > > > > > > > > > > Now, the chain traversal in get(x) could get to p when p.next == > > > > > > y, > > > > > > so then it goes to y, but then y.next=null could execute, and > > > > > > get(x) > > > > > > will think that the end of the chain has been reached and it > > > > > > will > > > > > > wrongly return null. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Deepak > > > diff -r 7f589f802faf ChangeLog > > --- a/ChangeLog Tue Apr 12 11:27:53 2011 -0400 > > +++ b/ChangeLog Tue Apr 12 12:14:32 2011 -0400 > > @@ -1,3 +1,17 @@ > > +2011-04-12 Denis Lila > > + > > + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > + Remove unused imports, added various SuppressWarnings annotations. > > + (createPanel): Return NetxPanel from doPriviledged. Remove dead code. > > + (PluginParseRequest): Remove - unused. > > + (defaultSaveFile, label, statusMsgStream, requests, handle): Remove - unused. > > + (identifier, appletPanels): Privatize. > > + (applets, status): Use ConcurrentHashMaps. > > + (framePanel, PluginAppletViewer): Remove unused PrintStream argument. > > + (forceredraw): Remove - unused. > > + (getApplets): Use generics. > > + (appletClose): Fix style to match our convention. > > + > > 2011-04-12 Denis Lila > > > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > diff -r 7f589f802faf plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Tue Apr 12 11:27:53 2011 -0400 > > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Tue Apr 12 12:14:32 2011 -0400 > > @@ -70,23 +70,19 @@ > > import java.awt.Graphics; > > import java.awt.Image; > > import java.awt.Insets; > > -import java.awt.Label; > > import java.awt.Toolkit; > > import java.awt.event.WindowAdapter; > > import java.awt.event.WindowEvent; > > import java.awt.event.WindowListener; > > import java.awt.print.PageFormat; > > import java.awt.print.Printable; > > -import java.io.BufferedReader; > > import java.io.IOException; > > import java.io.InputStream; > > -import java.io.InputStreamReader; > > import java.io.PrintStream; > > import java.io.Reader; > > import java.io.StringReader; > > import java.io.UnsupportedEncodingException; > > import java.lang.reflect.InvocationTargetException; > > -import java.net.MalformedURLException; > > import java.net.SocketPermission; > > import java.net.URI; > > import java.net.URL; > > @@ -128,49 +124,27 @@ > > long handle, int x, int y, > > final URL doc, > > final Hashtable atts) { > > - AppletViewerPanel panel = AccessController.doPrivileged(new PrivilegedAction() { > > - public AppletViewerPanel run() { > > - try { > > - AppletViewerPanel panel = new NetxPanel(doc, atts, false); > > - AppletViewerPanel.debug("Using NetX panel"); > > - PluginDebug.debug(atts.toString()); > > - return panel; > > - } catch (Exception ex) { > > - AppletViewerPanel.debug("Unable to start NetX applet - defaulting to Sun applet", ex); > > - return new AppletViewerPanel(doc, atts); > > - } > > + NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { > > + public NetxPanel run() { > > + NetxPanel panel = new NetxPanel(doc, atts, false); > > + NetxPanel.debug("Using NetX panel"); > > + PluginDebug.debug(atts.toString()); > > + return panel; > > } > > }); > > > > // create the frame. > > - PluginAppletViewer.framePanel(identifier, System.out, handle, panel); > > + PluginAppletViewer.framePanel(identifier, handle, panel); > > > > panel.init(); > > > > // Start the applet > > initEventQueue(panel); > > > > - // Applet initialized. Find out it's classloader and add it to the list > > - String portComponent = doc.getPort() != -1 ? ":" + doc.getPort() : ""; > > - String codeBase = doc.getProtocol() + "://" + doc.getHost() + portComponent; > > - > > - if (atts.get("codebase") != null) { > > - try { > > - URL appletSrcURL = new URL(codeBase + atts.get("codebase")); > > - codeBase = appletSrcURL.getProtocol() + "://" + appletSrcURL.getHost(); > > - } catch (MalformedURLException mfue) { > > - // do nothing > > - } > > - } > > - > > - // Wait for the panel to initialize > > - // (happens in a separate thread) > > - Applet a; > > - > > // Wait for panel to come alive > > int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > > int wait = 0; > > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait < maxWait)) { > > + while (!panel.isAlive() && wait < maxWait) { > > try { > > Thread.sleep(50); > > wait += 50; > > @@ -183,10 +157,10 @@ > > // (happens in a separate thread) > > PluginAppletViewer.waitForAppletInit((NetxPanel) panel); > > > > - a = panel.getApplet(); > > + Applet a = panel.getApplet(); > > > > // Still null? > > - if (panel.getApplet() == null) { > > + if (a == null) { > > streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > > return null; > > } > > @@ -194,8 +168,8 @@ > > PluginDebug.debug("Applet ", a.getClass(), " initialized"); > > streamhandler.write("instance " + identifier + " reference 0 initialized"); > > > > - AppletSecurityContextManager.getSecurityContext(0).associateSrc(((NetxPanel) panel).getAppletClassLoader(), doc); > > - AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, ((NetxPanel) panel).getAppletClassLoader()); > > + AppletSecurityContextManager.getSecurityContext(0).associateSrc(panel.getAppletClassLoader(), doc); > > + AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, panel.getAppletClassLoader()); > > > > return panel; > > } > > @@ -291,21 +265,12 @@ > > } > > } > > > > -class PluginParseRequest { > > - long handle; > > - String tag; > > - String documentbase; > > -} > > - > > /* > > */ > > // FIXME: declare JSProxy implementation > > + at SuppressWarnings("serial") > > public class PluginAppletViewer extends XEmbeddedFrame > > implements AppletContext, Printable { > > - /** > > - * Some constants... > > - */ > > - private static String defaultSaveFile = "Applet.ser"; > > > > /** > > * Enumerates the current status of an applet > > @@ -323,23 +288,9 @@ > > /** > > * The panel in which the applet is being displayed. > > */ > > - AppletViewerPanel panel; > > + private AppletViewerPanel panel; > > > > - /** > > - * The status line. > > - */ > > - Label label; > > - > > - /** > > - * output status messages to this stream > > - */ > > - > > - PrintStream statusMsgStream; > > - > > - int identifier; > > - > > - private static HashMap requests = > > - new HashMap(); > > + private int identifier; > > > > // Instance identifier -> PluginAppletViewer object. > > private static ConcurrentMap applets = > > @@ -352,7 +303,6 @@ > > private static ConcurrentMap status = > > new ConcurrentHashMap(); > > > > - private long handle = 0; > > private WindowListener windowEventListener = null; > > private AppletEventListener appletEventListener = null; > > > > @@ -370,15 +320,14 @@ > > public PluginAppletViewer() { > > } > > > > - public static void framePanel(int identifier, PrintStream statusMsgStream, > > - long handle, AppletViewerPanel panel) { > > + public static void framePanel(int identifier, long handle, NetxPanel panel) { > > > > PluginDebug.debug("Framing ", panel); > > > > // SecurityManager MUST be set, and only privileged code may call reFrame() > > System.getSecurityManager().checkPermission(new AllPermission()); > > > > - PluginAppletViewer appletFrame = new PluginAppletViewer(handle, identifier, statusMsgStream, panel); > > + PluginAppletViewer appletFrame = new PluginAppletViewer(handle, identifier, panel); > > > > appletFrame.add("Center", panel); > > appletFrame.pack(); > > @@ -395,11 +344,9 @@ > > * Create new plugin appletviewer frame > > */ > > private PluginAppletViewer(long handle, final int identifier, > > - PrintStream statusMsgStream, > > - AppletViewerPanel appletPanel) { > > + NetxPanel appletPanel) { > > > > super(handle, true); > > - this.statusMsgStream = statusMsgStream; > > this.identifier = identifier; > > this.panel = appletPanel; > > > > @@ -547,8 +494,6 @@ > > if (wait >= maxWait) > > throw new Exception("Applet initialization timeout"); > > > > - PluginAppletViewer oldFrame = applets.get(identifier); > > - > > // We should not try to destroy an applet during > > // initialization. It may cause an inconsistent state, > > // which would bad if it's a trusted applet that > > @@ -792,7 +737,7 @@ > > > > // Still null? > > if (panel.getApplet() == null) { > > - this.streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > > + streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > > return; > > } > > > > @@ -807,11 +752,6 @@ > > } > > } > > > > - // FIXME: Kind of hackish way to ensure synchronized re-drawing > > - private synchronized void forceredraw() { > > - doLayout(); > > - } > > - > > /* > > * Methods for java.applet.AppletContext > > */ > > @@ -910,8 +850,8 @@ > > SocketPermission panelSp = > > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > > synchronized(appletPanels) { > > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > > - AppletPanel p = (AppletPanel) e.nextElement(); > > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > > + AppletPanel p = e.nextElement(); > > String param = p.getParameter("name"); > > if (param != null) { > > param = param.toLowerCase(); > > @@ -1652,34 +1592,32 @@ > > // > > final AppletPanel p = panel; > > > > - new Thread(new Runnable() > > - { > > - public void run() > > - { > > - ClassLoader cl = p.applet.getClass().getClassLoader(); > > - > > - // Since we want to deal with JNLPClassLoader, extract it if this > > - // is a codebase loader > > - if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > > - cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); > > + new Thread(new Runnable() { > > + @SuppressWarnings("deprecation") > > + public void run() { > > + ClassLoader cl = p.applet.getClass().getClassLoader(); > > > > - ThreadGroup tg = ((JNLPClassLoader) cl).getApplication().getThreadGroup(); > > + // Since we want to deal with JNLPClassLoader, extract it if this > > + // is a codebase loader > > + if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > > + cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); > > > > - appletShutdown(p); > > - appletPanels.removeElement(p); > > - dispose(); > > + ThreadGroup tg = ((JNLPClassLoader) cl).getApplication().getThreadGroup(); > > > > - if (tg.activeCount() > 0) > > - tg.stop(); > > + appletShutdown(p); > > + appletPanels.removeElement(p); > > + dispose(); > > > > - if (countApplets() == 0) { > > - appletSystemExit(); > > - } > > + if (tg.activeCount() > 0) > > + tg.stop(); > > > > - updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); > > - } > > - }).start(); > > + if (countApplets() == 0) { > > + appletSystemExit(); > > + } > > > > + updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); > > + } > > + }).start(); > > } > > > > /** > > @@ -1868,6 +1806,7 @@ > > }); > > } > > > > + @SuppressWarnings("unused") > > public static void parse(int identifier, long handle, String width, > > String height, Reader in, URL url, > > PrintStream statusMsgStream, > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From jvanek at redhat.com Wed Apr 13 05:56:45 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Wed, 13 Apr 2011 14:56:45 +0200 Subject: Fwd: Re: [RFC] PR568: LWJGL Applets fail to work with IcedTea Plugin In-Reply-To: <4D8A27CF.8030707@redhat.com> References: <4D8A2242.4080206@redhat.com> <4D8A27CF.8030707@redhat.com> Message-ID: <4DA59D8D.8000000@redhat.com> On 03/23/2011 06:03 PM, Omair Majid wrote: > On 03/23/2011 12:39 PM, Jiri Vanek wrote: >> just want to mention - I'm working on (with) several LWJGL applets.... >> And i have noticed no problem after installing icedtea-web (head). >> > > Interesting. Any links to the applets that work? > > I can confirm that the applet in question (http://lwjgl.org/applet) does > not work with IcedTea-Web Plugin (using IcedTea-Web 1.1pre+r2d359e723fef+)" > > [...snip...] > Caused by: java.lang.NullPointerException > at > net.sourceforge.jnlp.runtime.JNLPClassLoader.getPermissions(JNLPClassLoader.java:596) > > [...snip...] > > And a little later: > > [...snip...] > Caused by: java.security.AccessControlException: access denied > (java.util.PropertyPermission org.lwjgl.util.Debug read) > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:393) > > [...snip...] > > Cheers, > Omair Sorry for confusion. My environment was bad configured. I'm unable to run lwjgl applets/jnlps. I can provide reproducers if wanted. btw - changes mentioned by deepak : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/013058.html Are currently in head or not? regards J. From dbhole at redhat.com Wed Apr 13 06:59:57 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 13 Apr 2011 09:59:57 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412230733.GP7262@rivendell.middle-earth.co.uk> References: <20110412200947.GL7262@rivendell.middle-earth.co.uk> <585433630.197789.1302641376341.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110412230733.GP7262@rivendell.middle-earth.co.uk> Message-ID: <20110413135957.GA10510@redhat.com> * Dr Andrew John Hughes [2011-04-12 19:07]: > On 16:49 Tue 12 Apr , Denis Lila wrote: > > > while (!applets.containsKey(identifier) && // Map is populated only by > > > reFrame > > > (wait < maxWait)) { > > > > > > try { > > > Thread.sleep(50); > > > wait += 50; > > > } catch (InterruptedException ie) { > > > // just wait > > > } > > > } > > > > > > Surely this should be a timed wait and additions to applets should be > > > accompanied by > > > a notifyAll? > > > > That's what I thought when I first saw this code. But this works, and I > > see no practical reason to change it. If you really think we should, I > > could do it, but it should be it's own changeset. > > > > I'm not saying it should be in the same changeset. I was enumerating problems > that still exist with these collections to counter your claim that switching > to CHMs will suddenly fix everything. It won't. > > The practical difference is this code will wake the thread every fifty milliseconds > and reading from the map. Using notifyAll would only wake waiting threads when the > map has changed. > I agree that this is an issue. I will post a separate patch for it. I am also working on another patch to remove use of HashMaps completely. All this discussion has made me realize that we are unnecessarily using HashMaps for something that needs simple indexed access. Please do commit the CHM change though, since it is already done and there is no guarantee that my patch won't have to be backed out later. Cheers, Deepak > > > PluginAppletViewer oldFrame = applets.get(identifier); > > > > > > // We should not try to destroy an applet during > > > // initialization. It may cause an inconsistent state, > > > // which would bad if it's a trusted applet that > > > // read/writes to files > > > waitForAppletInit((NetxPanel) applets.get(identifier).panel); > > > > > > The two get calls could retrieve different values if a put occurs in > > > the interim. > > > > Yes, but it doesn't matter. oldFrame is dead code. > > > > Then it needs ripping out so it doesn't confuse people. > > > > The cast to AppletPanel is redundant. > > > > The enumeration is not using generics, so we need the cast. > > > > Ok, so the enumeration needs fixing too. > > Is your other patch handling all this generification? I thought we'd caught most > of them. > > > > > > Indentation change. Shouldn't be in this patch. > > ...... > > > This looks like just brackets being added. Shouldn't be in this patch. > > > > The indentation changed because the code was wrapped in > > a synchronized block. Not putting it in this patch would be > > breaking style conventions. > > > > Ok. > > Please don't remove code from the mail which is being discussed. It was > difficult to verify this again here because you removed the code. > > > > To be frank, this class is a mess. > > > > I couldn't agree more. > > And it's not just this class. It's almost every class in the > > icedtea-web sun.applet package. > > > > As for the points you made that I didn't reply to: > > None of them were pointing out any mistakes in my patch, > > No, they were pointing out mistakes in your assumptions that > a switch to CHMs is a fix-all. It's a start, that's all, but > I'd prefer everything was fixed. > > > so can I push this patch, > > Yes. > > > and address some of them > > (in particular the comments on destroyApplet) in my second > > patch (the refactoring one)? > > > > Don't mix them up with other changes. Separate patches please. > > > Thank you, > > Denis. > > > > ----- Original Message ----- > > > On 15:23 Tue 12 Apr , Denis Lila wrote: > > > > > > snip... > > > > > > > > snip... > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at redhat.com Wed Apr 13 07:02:30 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 13 Apr 2011 10:02:30 -0400 Subject: Fwd: Re: [RFC] PR568: LWJGL Applets fail to work with IcedTea Plugin In-Reply-To: <4DA59D8D.8000000@redhat.com> References: <4D8A2242.4080206@redhat.com> <4D8A27CF.8030707@redhat.com> <4DA59D8D.8000000@redhat.com> Message-ID: <4DA5ACF6.3090108@redhat.com> On 04/13/2011 08:56 AM, Jiri Vanek wrote: > > Sorry for confusion. My environment was bad configured. I'm unable to > run lwjgl applets/jnlps. I can provide reproducers if wanted. Reproducers would be great. Are they available publicly? If so, could you please add links to those to the bug report? > btw - changes mentioned by deepak : > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-March/013058.html > Are currently in head or not? As stated in the email, I am waiting for the security redesign to be done (which is targeted for the IcedTea-Web 2.0 release) before I commit the patch. From what I have seen of lwjgl applets, they are trusted applets that load new (possibly untrusted and/or unsigned) CodeSources. While the patch makes sure that the new CodeSources are added to the runtime (so lwjgl applets work), I am not sure if it does that in a completely safe manner. The JNLPClassLoader (and the security system in general in netx) were not designed with the idea of loading new code, especially with possible security restrictions, after startup. Given that adding this patch could expose the users to security risks, I am electing to not commit the patch. Cheers, Omair From dlila at redhat.com Wed Apr 13 07:30:48 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 13 Apr 2011 10:30:48 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412214015.GH27867@redhat.com> Message-ID: <1469480166.241950.1302705048670.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Did you change any functionality in destroyApplet or is it just > spacing/style fixes? In the first patch the only functionality change in destroyApplet is this (and there are no spacing changes): - if (applets.containsKey(identifier)) - applets.get(identifier).dispose(); + PluginAppletViewer pav = applets.get(identifier); + if (pav != null) + pav.dispose(); Is that ok? Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-12 17:24]: > > > Andrew posted some valid concerns in another thread. After those > > > are > > > all resolved, OK from me. > > > > I replied to that e-mail. Some of those were invalid > > and I pointed those out. The others I think were good ... From dbhole at redhat.com Wed Apr 13 07:40:40 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 13 Apr 2011 10:40:40 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1469480166.241950.1302705048670.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110412214015.GH27867@redhat.com> <1469480166.241950.1302705048670.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110413144040.GC10510@redhat.com> * Denis Lila [2011-04-13 10:30]: > > Did you change any functionality in destroyApplet or is it just > > spacing/style fixes? > > In the first patch the only functionality change in destroyApplet > is this (and there are no spacing changes): > > - if (applets.containsKey(identifier)) > - applets.get(identifier).dispose(); > + PluginAppletViewer pav = applets.get(identifier); > + if (pav != null) > + pav.dispose(); > > Is that ok? > That is a concurrency related fix. Please put it in that patch. Cheers, Deepak > Regards, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-12 17:24]: > > > > Andrew posted some valid concerns in another thread. After those > > > > are > > > > all resolved, OK from me. > > > > > > I replied to that e-mail. Some of those were invalid > > > and I pointed those out. The others I think were good > ... From dlila at redhat.com Wed Apr 13 07:45:29 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 13 Apr 2011 10:45:29 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110413144040.GC10510@redhat.com> Message-ID: <1591606716.242217.1302705929661.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > That is a concurrency related fix. Please put it in that patch. In which patch? The first one? It's already in the first one. However, if all concurrency fixes should go in the same patch, I have some others that I have to put in. I'll post the 3rd version soon. Thank you, Denis. ----- Original Message ----- > * Denis Lila [2011-04-13 10:30]: > > > Did you change any functionality in destroyApplet or is it just > > > spacing/style fixes? > > > > In the first patch the only functionality change in destroyApplet > > is this (and there are no spacing changes): > > > > - if (applets.containsKey(identifier)) > > - applets.get(identifier).dispose(); > > + PluginAppletViewer pav = applets.get(identifier); > > + if (pav != null) > > + pav.dispose(); > > > > Is that ok? > > > > > Cheers, > Deepak > > > Regards, > > Denis. > > > > ----- Original Message ----- > > > * Denis Lila [2011-04-12 17:24]: > > > > > Andrew posted some valid concerns in another thread. After > > > > > those > > > > > are > > > > > all resolved, OK from me. > > > > > > > > I replied to that e-mail. Some of those were invalid > > > > and I pointed those out. The others I think were good > > ... From ahughes at redhat.com Wed Apr 13 08:16:26 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 13 Apr 2011 16:16:26 +0100 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1591606716.242217.1302705929661.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110413144040.GC10510@redhat.com> <1591606716.242217.1302705929661.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110413151626.GW7262@rivendell.middle-earth.co.uk> On 10:45 Wed 13 Apr , Denis Lila wrote: > > That is a concurrency related fix. Please put it in that patch. > > In which patch? The first one? It's already in the first one. > > However, if all concurrency fixes should go in the same patch, > I have some others that I have to put in. I'll post the 3rd version > soon. > No, the first one was approved and should have gone in. > Thank you, > Denis. > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Wed Apr 13 08:56:57 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 13 Apr 2011 11:56:57 -0400 Subject: IcedTea-Web 1.1 branching on Wesnesday In-Reply-To: <20110411201208.GA6019@redhat.com> References: <20110411201208.GA6019@redhat.com> Message-ID: <20110413155657.GC28506@redhat.com> Hi, I sent this email on Monday but it seems that the original email didn't end up in inboxes even though it is on the site :/ If you did get the email, please note the updated schedule. ... Significant development has been done on IcedTea-Web since 1.0 was branched and I think it is time to start thinking of 1.1. I was thinking of branching at end of Friday (Apr. 15th) and then a release on the 28th after making sure things are stable. Once branched, no more features will be allowed in. Please let me know if you have any concerns about the above dates. Cheers, Deepak From dbhole at redhat.com Wed Apr 13 09:00:25 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 13 Apr 2011 12:00:25 -0400 Subject: IcedTea-Web 1.1 branching on _Friday_ In-Reply-To: <20110413155657.GC28506@redhat.com> References: <20110411201208.GA6019@redhat.com> <20110413155657.GC28506@redhat.com> Message-ID: <20110413160025.GD28506@redhat.com> Annnddd of course, I forgot to update $subject ... fixed * Deepak Bhole [2011-04-13 11:57]: > Hi, > > I sent this email on Monday but it seems that the original > email didn't end up in inboxes even though it is on the > site :/ If you did get the email, please note the updated > schedule. > > ... > > Significant development has been done on IcedTea-Web since 1.0 was > branched and I think it is time to start thinking of 1.1. I was > thinking of branching at end of Friday (Apr. 15th) and then a > release on the 28th after making sure things are stable. > > Once branched, no more features will be allowed in. > > Please let me know if you have any concerns about the above dates. > > Cheers, > Deepak From dlila at redhat.com Wed Apr 13 09:09:23 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 13 Apr 2011 12:09:23 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110413151626.GW7262@rivendell.middle-earth.co.uk> Message-ID: <1477678623.244296.1302710963863.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > No, the first one was approved and should have gone in. Ah, good. This makes things easier for me. Thank you, Denis. ----- Original Message ----- > On 10:45 Wed 13 Apr , Denis Lila wrote: > > > That is a concurrency related fix. Please put it in that patch. > > > > In which patch? The first one? It's already in the first one. > > > > However, if all concurrency fixes should go in the same patch, > > I have some others that I have to put in. I'll post the 3rd version > > soon. > > > > > > Thank you, > > Denis. > > > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at icedtea.classpath.org Wed Apr 13 09:17:57 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Wed, 13 Apr 2011 16:17:57 +0000 Subject: /hg/icedtea-web: Fix some concurrency problems in PluginAppletVi... Message-ID: changeset c84f2e5b039f in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=c84f2e5b039f author: Denis Lila date: Wed Apr 13 12:18:38 2011 -0400 Fix some concurrency problems in PluginAppletViewer.java. diffstat: ChangeLog | 10 ++ plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 61 +++++++++------ 2 files changed, 45 insertions(+), 26 deletions(-) diffs (140 lines): diff -r 934543b8084d -r c84f2e5b039f ChangeLog --- a/ChangeLog Mon Apr 11 16:03:44 2011 +0100 +++ b/ChangeLog Wed Apr 13 12:18:38 2011 -0400 @@ -1,3 +1,13 @@ +2011-04-12 Denis Lila + + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java + (applets, status): Make concurrent. + (PluginAppletViewer): Synchronize appletPanels addElement. + (destroyApplet): Remove applets.containsKey because it and the + get that followed it were not atomic. + (appletPanels): Privatize. + (getApplet, getApplets): Synchronize iteration. + 2011-04-08 Omair Majid * README: Update to add notes on rhino and junit. diff -r 934543b8084d -r c84f2e5b039f plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Apr 11 16:03:44 2011 +0100 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 12:18:38 2011 -0400 @@ -103,6 +103,8 @@ import java.util.List; import java.util.Map; import java.util.Vector; +import java.util.concurrent.ConcurrentHashMap; +import java.util.concurrent.ConcurrentMap; import javax.swing.SwingUtilities; @@ -340,15 +342,15 @@ new HashMap(); // Instance identifier -> PluginAppletViewer object. - private static HashMap applets = - new HashMap(); + private static ConcurrentMap applets = + new ConcurrentHashMap(); private static PluginStreamHandler streamhandler; private static PluginCallRequestFactory requestFactory; - private static HashMap status = - new HashMap(); + private static ConcurrentMap status = + new ConcurrentHashMap(); private long handle = 0; private WindowListener windowEventListener = null; @@ -401,8 +403,10 @@ this.identifier = identifier; this.panel = appletPanel; - if (!appletPanels.contains(panel)) - appletPanels.addElement(panel); + synchronized(appletPanels) { + if (!appletPanels.contains(panel)) + appletPanels.addElement(panel); + } windowEventListener = new WindowAdapter() { @@ -656,8 +660,9 @@ PluginDebug.debug("Attempting to destroy frame ", identifier); // Try to dispose the panel right away - if (applets.containsKey(identifier)) - applets.get(identifier).dispose(); + PluginAppletViewer pav = applets.get(identifier); + if (pav != null) + pav.dispose(); // If panel is already disposed, return if (applets.get(identifier).panel.applet == null) { @@ -895,7 +900,7 @@ imageRefs.clear(); } - static Vector appletPanels = new Vector(); + private static Vector appletPanels = new Vector(); /** * Get an applet by name. @@ -904,20 +909,22 @@ name = name.toLowerCase(); SocketPermission panelSp = new SocketPermission(panel.getCodeBase().getHost(), "connect"); - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { - AppletPanel p = (AppletPanel) e.nextElement(); - String param = p.getParameter("name"); - if (param != null) { - param = param.toLowerCase(); - } - if (name.equals(param) && - p.getDocumentBase().equals(panel.getDocumentBase())) { + synchronized(appletPanels) { + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { + AppletPanel p = (AppletPanel) e.nextElement(); + String param = p.getParameter("name"); + if (param != null) { + param = param.toLowerCase(); + } + if (name.equals(param) && + p.getDocumentBase().equals(panel.getDocumentBase())) { - SocketPermission sp = + SocketPermission sp = new SocketPermission(p.getCodeBase().getHost(), "connect"); - if (panelSp.implies(sp)) { - return p.applet; + if (panelSp.implies(sp)) { + return p.applet; + } } } } @@ -933,14 +940,16 @@ SocketPermission panelSp = new SocketPermission(panel.getCodeBase().getHost(), "connect"); - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { - AppletPanel p = e.nextElement(); - if (p.getDocumentBase().equals(panel.getDocumentBase())) { + synchronized(appletPanels) { + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { + AppletPanel p = e.nextElement(); + if (p.getDocumentBase().equals(panel.getDocumentBase())) { - SocketPermission sp = + SocketPermission sp = new SocketPermission(p.getCodeBase().getHost(), "connect"); - if (panelSp.implies(sp)) { - v.addElement(p.applet); + if (panelSp.implies(sp)) { + v.addElement(p.applet); + } } } } From dlila at redhat.com Wed Apr 13 12:10:36 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 13 Apr 2011 15:10:36 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110412231012.GQ7262@rivendell.middle-earth.co.uk> Message-ID: <155609954.255088.1302721836941.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > If a patch akin to > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > goes in, I will not be responsible for my actions. I definitely don't want that ;-). Attached is the second patch. It's mostly cleanup, and it also uses "pav" in destroyApplet, instead of calling get(id) again and again. Ok to push? Thank you, Denis. ----- Original Message ----- > On 17:40 Tue 12 Apr , Deepak Bhole wrote: > > * Denis Lila [2011-04-12 17:24]: > > > > Andrew posted some valid concerns in another thread. After those > > > > are > > > > all resolved, OK from me. > > > > > > I replied to that e-mail. Some of those were invalid > > > and I pointed those out. The others I think were good > > > points but they weren't directly related to this patch, > > > so I think they should be fixed in a future changeset. >... -------------- next part -------------- A non-text attachment was scrubbed... Name: RefactorPAV.patch Type: text/x-patch Size: 19045 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110413/82a45535/RefactorPAV.patch From asu at redhat.com Wed Apr 13 13:01:17 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 13 Apr 2011 16:01:17 -0400 (EDT) Subject: [RFC][Icedtea-Web]: make CacheDirectory class final In-Reply-To: <2073662684.78330.1302724838907.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <437316425.78339.1302724877207.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hi, This patch is to make the net.sourceforge.jnlp.cache.CacheDirectory a final class, since it shouldn't be extensible as pointed out by Denis. Changelog: * netx/net/sourceforge/jnlp/cache/CacheDirectory.java: Added final modifier to class declaration. (CacheDirectory): New private constructor. Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110413_make_final.patch Type: text/x-patch Size: 575 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110413/9173ebd3/20110413_make_final.patch From asu at redhat.com Wed Apr 13 13:23:27 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 13 Apr 2011 16:23:27 -0400 (EDT) Subject: [RFC][Icedtea-Web]: make CacheDirectory class final In-Reply-To: <437316425.78339.1302724877207.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <312983582.78818.1302726207842.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Seems like this email didn't make it back to my inbox.. Resending. http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013566.html ----- Original Message ----- > From: "Andrew Su" > To: "IcedTea" > Sent: Wednesday, April 13, 2011 4:01:17 PM > Subject: [RFC][Icedtea-Web]: make CacheDirectory class final > Hi, > > This patch is to make the net.sourceforge.jnlp.cache.CacheDirectory a > final class, since it shouldn't be extensible as pointed out by Denis. > > Changelog: > * netx/net/sourceforge/jnlp/cache/CacheDirectory.java: > Added final modifier to class declaration. > (CacheDirectory): New private constructor. > > Cheers, > Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110413_make_final.patch Type: text/x-patch Size: 575 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110413/1bb2e7ac/20110413_make_final.patch From dbhole at redhat.com Wed Apr 13 14:10:36 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 13 Apr 2011 17:10:36 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <155609954.255088.1302721836941.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110412231012.GQ7262@rivendell.middle-earth.co.uk> <155609954.255088.1302721836941.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110413211035.GF28506@redhat.com> * Denis Lila [2011-04-13 15:10]: > > If a patch akin to > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > goes in, I will not be responsible for my actions. > > I definitely don't want that ;-). > > Attached is the second patch. It's mostly cleanup, and it > also uses "pav" in destroyApplet, instead of calling > get(id) again and again. > > Ok to push? > ... ... > > PluginDebug.debug("getCachedImageRef() getting img from URL = ", url); > @@ -910,8 +815,8 @@ > SocketPermission panelSp = > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > synchronized(appletPanels) { > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > - AppletPanel p = (AppletPanel) e.nextElement(); > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > + AppletPanel p = e.nextElement(); > String param = p.getParameter("name"); > if (param != null) { > param = param.toLowerCase(); > @@ -1591,15 +1496,15 @@ > * at the same time. > */ > try { > - panel.joinAppletThread(); > - panel.release(); > + ((AppletViewerPanel)panel).joinAppletThread(); > + ((AppletViewerPanel)panel).release(); > } catch (InterruptedException e) { > return; // abort the reload > } > > AccessController.doPrivileged(new PrivilegedAction() { > public Void run() { > - panel.createAppletThread(); > + ((AppletViewerPanel)panel).createAppletThread(); > return null; > } Instead of doing this, it would be easier to change the type of appletPanels to Vector , then the casting is not needed as AVP inherits from AP. From dbhole at redhat.com Wed Apr 13 14:12:06 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 13 Apr 2011 17:12:06 -0400 Subject: [RFC][Icedtea-Web]: make CacheDirectory class final In-Reply-To: <312983582.78818.1302726207842.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <437316425.78339.1302724877207.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <312983582.78818.1302726207842.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110413211206.GG28506@redhat.com> * Andrew Su [2011-04-13 16:24]: > Seems like this email didn't make it back to my inbox.. Resending. > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013566.html > Okay for head. Deepak > ----- Original Message ----- > > From: "Andrew Su" > > To: "IcedTea" > > Sent: Wednesday, April 13, 2011 4:01:17 PM > > Subject: [RFC][Icedtea-Web]: make CacheDirectory class final > > Hi, > > > > This patch is to make the net.sourceforge.jnlp.cache.CacheDirectory a > > final class, since it shouldn't be extensible as pointed out by Denis. > > > > Changelog: > > * netx/net/sourceforge/jnlp/cache/CacheDirectory.java: > > Added final modifier to class declaration. > > (CacheDirectory): New private constructor. > > > > Cheers, > > Andrew > diff -r c84f2e5b039f netx/net/sourceforge/jnlp/cache/CacheDirectory.java > --- a/netx/net/sourceforge/jnlp/cache/CacheDirectory.java Wed Apr 13 12:18:38 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheDirectory.java Wed Apr 13 15:59:03 2011 -0400 > @@ -41,7 +41,11 @@ > > import net.sourceforge.jnlp.util.FileUtils; > > -public class CacheDirectory { > +public final class CacheDirectory { > + > + /* Don't allow instantiation of this class */ > + private CacheDirectory(){} > + > /** > * Get the structure of directory for keeping track of the protocol and > * domain. From asu at icedtea.classpath.org Wed Apr 13 14:22:00 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Wed, 13 Apr 2011 21:22:00 +0000 Subject: /hg/icedtea-web: Make CacheDirectory final and not instantiable. Message-ID: changeset 1e661bc821f8 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=1e661bc821f8 author: Andrew Su date: Wed Apr 13 17:23:49 2011 -0400 Make CacheDirectory final and not instantiable. diffstat: ChangeLog | 6 ++++++ netx/net/sourceforge/jnlp/cache/CacheDirectory.java | 6 +++++- 2 files changed, 11 insertions(+), 1 deletions(-) diffs (29 lines): diff -r c84f2e5b039f -r 1e661bc821f8 ChangeLog --- a/ChangeLog Wed Apr 13 12:18:38 2011 -0400 +++ b/ChangeLog Wed Apr 13 17:23:49 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-13 Andrew Su + + * netx/net/sourceforge/jnlp/cache/CacheDirectory.java: + Added final modifier to class declaration. + (CacheDirectory): New private constructor. + 2011-04-12 Denis Lila * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java diff -r c84f2e5b039f -r 1e661bc821f8 netx/net/sourceforge/jnlp/cache/CacheDirectory.java --- a/netx/net/sourceforge/jnlp/cache/CacheDirectory.java Wed Apr 13 12:18:38 2011 -0400 +++ b/netx/net/sourceforge/jnlp/cache/CacheDirectory.java Wed Apr 13 17:23:49 2011 -0400 @@ -41,7 +41,11 @@ import net.sourceforge.jnlp.util.FileUtils; -public class CacheDirectory { +public final class CacheDirectory { + + /* Don't allow instantiation of this class */ + private CacheDirectory(){} + /** * Get the structure of directory for keeping track of the protocol and * domain. From dbhole at redhat.com Wed Apr 13 17:48:03 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 13 Apr 2011 20:48:03 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true Message-ID: <20110414004803.GA3875@redhat.com> Hi, Andrew mentioned in one of the previous threads that the current plugin code waits in an inefficient manner. It wakes up periodically to check for conditions, and goes back to sleep, and keeps doing that cyclically. The attached patch uses a new function that uses object.wait for the object of interest. ChangeLog: 2011-04-13 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (createPanel): use Object.wait() to wait, rather than pariodic sleep. (framePanel): Notify threads waiting on the applets map instance. (appletStateChanged): Notify all threads waiting on the panel that just changed state. (handleMessage): Use the new waitTillTimeout function to wait, rather than periodically waking up. (updateStatus): Notify all threads waiting on status map. (waitForAppletInit): Use the new waitTillTimeout function to wait, rather than periodically waking up. (waitTillTimeout): New function. For a given non-null object, waits until the specified timeout, or, if an interrupt was thrown during wait, returns immediately. The patch is based on top of Denis's lastest refactoring patch (since a lot of the surrounding code was touched and that patch will most likely go in very soon). Comments? Cheers, Deepak -------------- next part -------------- diff -r 2ef65ff10619 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 19:17:21 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 20:39:23 2011 -0400 @@ -91,12 +91,10 @@ import java.security.PrivilegedAction; import java.security.PrivilegedActionException; import java.security.PrivilegedExceptionAction; -import java.util.ArrayList; import java.util.Enumeration; import java.util.HashMap; import java.util.Hashtable; import java.util.Iterator; -import java.util.List; import java.util.Map; import java.util.Vector; import java.util.concurrent.ConcurrentHashMap; @@ -142,15 +140,17 @@ initEventQueue(panel); // Wait for panel to come alive - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while (!panel.isAlive() && wait < maxWait) { + // Wait implemented the long way so that + // PluginAppletViewer.waitTillTimeout() needn't be exposed. + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; + while (!panel.isAlive() && maxTimeToSleep > 0) { + long sleepStart = System.currentTimeMillis(); + try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait - } + panel.wait(maxTimeToSleep); + } catch (InterruptedException e) {} // Just loop back + + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); } // Wait for the panel to initialize @@ -307,6 +307,10 @@ panel.addAppletListener(appletFrame.appletEventListener); applets.put(identifier, appletFrame); + + synchronized(applets) { + applets.notifyAll(); + } PluginDebug.debug(panel, " framed"); } @@ -357,6 +361,11 @@ public void appletStateChanged(AppletEvent evt) { AppletPanel src = (AppletPanel) evt.getSource(); + PluginDebug.debug("Notifying all for ", src); + synchronized (src) { + src.notifyAll(); + } + switch (evt.getID()) { case AppletPanel.APPLET_RESIZE: { if (src != null) { @@ -448,21 +457,14 @@ new StringReader(tag), new URL(documentBase)); - int maxWait = APPLET_TIMEOUT; // wait for applet to fully load - int wait = 0; - while (!applets.containsKey(identifier) && // Map is populated only by reFrame - (wait < maxWait)) { - - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait - } + long maxTimeToSleep = APPLET_TIMEOUT; + while (!applets.containsKey(identifier) && + maxTimeToSleep > 0) { // Map is populated only by reFrame + maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); } // If wait exceeded maxWait, we timed out. Throw an exception - if (wait >= maxWait) + if (maxTimeToSleep <= 0) throw new Exception("Applet initialization timeout"); // We should not try to destroy an applet during @@ -547,6 +549,10 @@ // Else set to given status status.put(identifier, newStatus); + + synchronized(status) { + status.notifyAll(); + } return prev; } @@ -599,7 +605,9 @@ } /** - * Function to block until applet initialization is complete + * Function to block until applet initialization is complete. + * + * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} * * @param panel the instance to wait for. */ @@ -608,17 +616,12 @@ int waitTime = 0; // Wait till initialization finishes + long maxTimeToSleep = APPLET_TIMEOUT; while (panel.getApplet() == null && panel.isAlive() && - waitTime < APPLET_TIMEOUT) { - try { - if (waitTime % 500 == 0) - PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); - - Thread.sleep(waitTime += 50); - } catch (InterruptedException ie) { - // just wait - } + maxTimeToSleep > 0) { + PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); } PluginDebug.debug("Applet panel ", panel, " initialized"); @@ -628,15 +631,10 @@ if (message.startsWith("width")) { // Wait for panel to come alive - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && wait < maxWait) { - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait - } + int maxTimeToSleep = APPLET_TIMEOUT; + while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && + maxTimeToSleep > 0) { + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); } // 0 => width, 1=> width_value, 2 => height, 3=> height_value @@ -688,16 +686,16 @@ Object o; // Wait for panel to come alive - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait - } - } + long maxTimeToSleep = APPLET_TIMEOUT; + + // First, wait for panel to instantiate + while (panel == null && maxTimeToSleep > 0) + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); + + // Next, wait for panel to come alive + maxTimeToSleep = APPLET_TIMEOUT; + while (!panel.isAlive()) + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); // Wait for the panel to initialize // (happens in a separate thread) @@ -2049,4 +2047,35 @@ // Draw the painted image g.drawImage(bufFrameImg, 0, 0, this); } + + /** + * Waits on a given object until timeout. + * + * If the given object is null, this function returns immediately. + * + * @param obj The object to wait on + * @param timeout The maximum time to wait + * @return Approximate time spend sleeping (not guaranteed to be perfect) + */ + public static long waitTillTimeout(Object obj, long timeout) { + + // Can't wait on null. Return 0 indicating no wait happened. + if (obj == null) + return 0; + + // Record when we started sleeping + long sleepStart = System.currentTimeMillis(); + + try { + synchronized(obj) { + obj.wait(timeout); + } + } catch (InterruptedException ie) {} // Discarded, time to return + + // Record when we woke up + long sleepEnd = System.currentTimeMillis(); + + // Return the difference + return sleepEnd - sleepStart; + } } From dbhole at redhat.com Wed Apr 13 22:56:57 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 01:56:57 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414004803.GA3875@redhat.com> References: <20110414004803.GA3875@redhat.com> Message-ID: <20110414055656.GA18391@redhat.com> * Deepak Bhole [2011-04-13 20:48]: > Hi, > > Andrew mentioned in one of the previous threads that the current plugin > code waits in an inefficient manner. It wakes up periodically to > check for conditions, and goes back to sleep, and keeps doing that > cyclically. > > The attached patch uses a new function that uses object.wait for > the object of interest. > Please see attached new patch. After leaving the office I realized that there is a potential race condition in the old patch with locking the object inside the wait function. Patch updated to do the locking outside (and function comment updated to clearly state that). Cheers, Deepak -------------- next part -------------- diff -r 2ef65ff10619 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 19:17:21 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 01:54:04 2011 -0400 @@ -91,12 +91,10 @@ import java.security.PrivilegedAction; import java.security.PrivilegedActionException; import java.security.PrivilegedExceptionAction; -import java.util.ArrayList; import java.util.Enumeration; import java.util.HashMap; import java.util.Hashtable; import java.util.Iterator; -import java.util.List; import java.util.Map; import java.util.Vector; import java.util.concurrent.ConcurrentHashMap; @@ -142,14 +140,19 @@ initEventQueue(panel); // Wait for panel to come alive - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while (!panel.isAlive() && wait < maxWait) { - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + // Wait implemented the long way so that + // PluginAppletViewer.waitTillTimeout() needn't be exposed. + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; + + synchronized(panel) { + while (!panel.isAlive() && maxTimeToSleep > 0) { + long sleepStart = System.currentTimeMillis(); + + try { + panel.wait(maxTimeToSleep); + } catch (InterruptedException e) {} // Just loop back + + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); } } @@ -307,6 +310,10 @@ panel.addAppletListener(appletFrame.appletEventListener); applets.put(identifier, appletFrame); + + synchronized(applets) { + applets.notifyAll(); + } PluginDebug.debug(panel, " framed"); } @@ -357,6 +364,10 @@ public void appletStateChanged(AppletEvent evt) { AppletPanel src = (AppletPanel) evt.getSource(); + synchronized (src) { + src.notifyAll(); + } + switch (evt.getID()) { case AppletPanel.APPLET_RESIZE: { if (src != null) { @@ -448,21 +459,16 @@ new StringReader(tag), new URL(documentBase)); - int maxWait = APPLET_TIMEOUT; // wait for applet to fully load - int wait = 0; - while (!applets.containsKey(identifier) && // Map is populated only by reFrame - (wait < maxWait)) { - - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + long maxTimeToSleep = APPLET_TIMEOUT; + synchronized(applets) { + while (!applets.containsKey(identifier) && + maxTimeToSleep > 0) { // Map is populated only by reFrame + maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); } } // If wait exceeded maxWait, we timed out. Throw an exception - if (wait >= maxWait) + if (maxTimeToSleep <= 0) throw new Exception("Applet initialization timeout"); // We should not try to destroy an applet during @@ -547,6 +553,10 @@ // Else set to given status status.put(identifier, newStatus); + + synchronized(status) { + status.notifyAll(); + } return prev; } @@ -599,7 +609,9 @@ } /** - * Function to block until applet initialization is complete + * Function to block until applet initialization is complete. + * + * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} * * @param panel the instance to wait for. */ @@ -608,16 +620,14 @@ int waitTime = 0; // Wait till initialization finishes - while (panel.getApplet() == null && - panel.isAlive() && - waitTime < APPLET_TIMEOUT) { - try { - if (waitTime % 500 == 0) - PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); + long maxTimeToSleep = APPLET_TIMEOUT; - Thread.sleep(waitTime += 50); - } catch (InterruptedException ie) { - // just wait + synchronized(panel) { + while (panel.getApplet() == null && + panel.isAlive() && + maxTimeToSleep > 0) { + PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); } } @@ -628,14 +638,11 @@ if (message.startsWith("width")) { // Wait for panel to come alive - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && wait < maxWait) { - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + int maxTimeToSleep = APPLET_TIMEOUT; + synchronized(status) { + while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && + maxTimeToSleep > 0) { + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); } } @@ -686,17 +693,21 @@ // FIXME: how do we determine what security context this // object should belong to? Object o; - - // Wait for panel to come alive - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { + + // First, wait for panel to instantiate + int waited = 0; + while (panel == null && waited < APPLET_TIMEOUT) { try { Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait - } + waited += 50; + } catch (InterruptedException ie) {} // discard, loop back + } + + // Next, wait for panel to come alive + long maxTimeToSleep = APPLET_TIMEOUT; + synchronized(panel) { + while (!panel.isAlive()) + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); } // Wait for the panel to initialize @@ -2049,4 +2060,36 @@ // Draw the painted image g.drawImage(bufFrameImg, 0, 0, this); } + + /** + * Waits on a given object until timeout. + * + * This function assumes that the monitor lock has already been + * acquired by the caller. + * + * If the given object is null, this function returns immediately. + * + * @param obj The object to wait on + * @param timeout The maximum time to wait + * @return Approximate time spent sleeping (not guaranteed to be perfect) + */ + public static long waitTillTimeout(Object obj, long timeout) { + + // Can't wait on null. Return 0 indicating no wait happened. + if (obj == null) + return 0; + + // Record when we started sleeping + long sleepStart = System.currentTimeMillis(); + + try { + obj.wait(timeout); + } catch (InterruptedException ie) {} // Discarded, time to return + + // Record when we woke up + long sleepEnd = System.currentTimeMillis(); + + // Return the difference + return sleepEnd - sleepStart; + } } From jvanek at redhat.com Thu Apr 14 03:25:27 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 14 Apr 2011 12:25:27 +0200 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414055656.GA18391@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> Message-ID: <4DA6CB97.40805@redhat.com> On 04/14/2011 07:56 AM, Deepak Bhole wrote: > * Deepak Bhole [2011-04-13 20:48]: >> > Hi, >> > >> > Andrew mentioned in one of the previous threads that the current plugin >> > code waits in an inefficient manner. It wakes up periodically to >> > check for conditions, and goes back to sleep, and keeps doing that >> > cyclically. >> > >> > The attached patch uses a new function that uses object.wait for >> > the object of interest. >> > > Please see attached new patch. After leaving the office I realized that > there is a potential race condition in the old patch with locking the > object inside the wait function. Patch updated to do the locking > outside (and function comment updated to clearly state that). > > Cheers, > Deepak > > > wait-fixes.patch > > > diff -r 2ef65ff10619 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 19:17:21 2011 -0400 > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 01:54:04 2011 -0400 > @@ -91,12 +91,10 @@ > import java.security.PrivilegedAction; > import java.security.PrivilegedActionException; > import java.security.PrivilegedExceptionAction; > -import java.util.ArrayList; > import java.util.Enumeration; > import java.util.HashMap; > import java.util.Hashtable; > import java.util.Iterator; > -import java.util.List; > import java.util.Map; > import java.util.Vector; > import java.util.concurrent.ConcurrentHashMap; > @@ -142,14 +140,19 @@ > initEventQueue(panel); > > // Wait for panel to come alive > - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > - int wait = 0; > - while (!panel.isAlive()&& wait< maxWait) { > - try { > - Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > + // Wait implemented the long way so that > + // PluginAppletViewer.waitTillTimeout() needn't be exposed. > + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > + > + synchronized(panel) { > + while (!panel.isAlive()&& maxTimeToSleep> 0) { > + long sleepStart = System.currentTimeMillis(); > + > + try { > + panel.wait(maxTimeToSleep); > + } catch (InterruptedException e) {} // Just loop back > + > + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); > } > } > > @@ -307,6 +310,10 @@ > panel.addAppletListener(appletFrame.appletEventListener); > > applets.put(identifier, appletFrame); > + > + synchronized(applets) { > + applets.notifyAll(); > + } > > PluginDebug.debug(panel, " framed"); > } > @@ -357,6 +364,10 @@ > public void appletStateChanged(AppletEvent evt) { > AppletPanel src = (AppletPanel) evt.getSource(); > > + synchronized (src) { > + src.notifyAll(); > + } > + > switch (evt.getID()) { > case AppletPanel.APPLET_RESIZE: { > if (src != null) { > @@ -448,21 +459,16 @@ > new StringReader(tag), > new URL(documentBase)); > > - int maxWait = APPLET_TIMEOUT; // wait for applet to fully load > - int wait = 0; > - while (!applets.containsKey(identifier)&& // Map is populated only by reFrame > - (wait< maxWait)) { > - > - try { > - Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > + long maxTimeToSleep = APPLET_TIMEOUT; > + synchronized(applets) { > + while (!applets.containsKey(identifier)&& > + maxTimeToSleep> 0) { // Map is populated only by reFrame > + maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); > } > } > > // If wait exceeded maxWait, we timed out. Throw an exception > - if (wait>= maxWait) > + if (maxTimeToSleep<= 0) > throw new Exception("Applet initialization timeout"); > > // We should not try to destroy an applet during > @@ -547,6 +553,10 @@ > > // Else set to given status > status.put(identifier, newStatus); > + > + synchronized(status) { > + status.notifyAll(); > + } > > return prev; > } > @@ -599,7 +609,9 @@ > } > > /** > - * Function to block until applet initialization is complete > + * Function to block until applet initialization is complete. > + * > + * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} > * > * @param panel the instance to wait for. > */ > @@ -608,16 +620,14 @@ > int waitTime = 0; > > // Wait till initialization finishes > - while (panel.getApplet() == null&& > - panel.isAlive()&& > - waitTime< APPLET_TIMEOUT) { > - try { > - if (waitTime % 500 == 0) > - PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); > + long maxTimeToSleep = APPLET_TIMEOUT; > > - Thread.sleep(waitTime += 50); > - } catch (InterruptedException ie) { > - // just wait > + synchronized(panel) { > + while (panel.getApplet() == null&& > + panel.isAlive()&& > + maxTimeToSleep> 0) { > + PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); > + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > } > } > > @@ -628,14 +638,11 @@ > if (message.startsWith("width")) { > > // Wait for panel to come alive > - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive > - int wait = 0; > - while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE)&& wait< maxWait) { > - try { > - Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > + int maxTimeToSleep = APPLET_TIMEOUT; > + synchronized(status) { > + while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE)&& > + maxTimeToSleep> 0) { > + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); > } > } > > @@ -686,17 +693,21 @@ > // FIXME: how do we determine what security context this > // object should belong to? > Object o; > - > - // Wait for panel to come alive > - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive > - int wait = 0; > - while ((panel == null) || (!panel.isAlive()&& wait< maxWait)) { > + > + // First, wait for panel to instantiate > + int waited = 0; > + while (panel == null&& waited< APPLET_TIMEOUT) { > try { > Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > - } > + waited += 50; > + } catch (InterruptedException ie) {} // discard, loop back > + } > + > + // Next, wait for panel to come alive > + long maxTimeToSleep = APPLET_TIMEOUT; > + synchronized(panel) { > + while (!panel.isAlive()) > + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > } > > // Wait for the panel to initialize > @@ -2049,4 +2060,36 @@ > // Draw the painted image > g.drawImage(bufFrameImg, 0, 0, this); > } > + > + /** > + * Waits on a given object until timeout. > + * > + *This function assumes that the monitor lock has already been > + * acquired by the caller. > + * > + * If the given object is null, this function returns immediately. > + * > + * @param obj The object to wait on > + * @param timeout The maximum time to wait > + * @return Approximate time spent sleeping (not guaranteed to be perfect) > + */ > + public static long waitTillTimeout(Object obj, long timeout) { > + > + // Can't wait on null. Return 0 indicating no wait happened. > + if (obj == null) > + return 0; > + > + // Record when we started sleeping > + long sleepStart = System.currentTimeMillis(); > + > + try { > + obj.wait(timeout); > + } catch (InterruptedException ie) {} // Discarded, time to return > + > + // Record when we woke up > + long sleepEnd = System.currentTimeMillis(); > + > + // Return the difference > + return sleepEnd - sleepStart; > + } > } I'm expecting Andrew will say something about missing changelog(!) or something like that O:) But I have found no problem here. For me push OK. regards J. From ahughes at redhat.com Thu Apr 14 04:41:00 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 12:41:00 +0100 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414055656.GA18391@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> Message-ID: <20110414114100.GC7262@rivendell.middle-earth.co.uk> On 01:56 Thu 14 Apr , Deepak Bhole wrote: > * Deepak Bhole [2011-04-13 20:48]: > > Hi, > > > > Andrew mentioned in one of the previous threads that the current plugin > > code waits in an inefficient manner. It wakes up periodically to > > check for conditions, and goes back to sleep, and keeps doing that > > cyclically. > > > > The attached patch uses a new function that uses object.wait for > > the object of interest. > > > > Please see attached new patch. After leaving the office I realized that > there is a potential race condition in the old patch with locking the > object inside the wait function. Patch updated to do the locking > outside (and function comment updated to clearly state that). > Can you elaborate? If it's the same thread acquiring the lock in both cases, then it should be fine as they are re-entrant i.e. if the function attempts to lock it and the thread already holds the lock, it's a no-op. > Cheers, > Deepak Comments inline. As Jiri said, a ChangeLog would be good too. > diff -r 2ef65ff10619 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 19:17:21 2011 -0400 > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 01:54:04 2011 -0400 > @@ -91,12 +91,10 @@ > import java.security.PrivilegedAction; > import java.security.PrivilegedActionException; > import java.security.PrivilegedExceptionAction; > -import java.util.ArrayList; > import java.util.Enumeration; > import java.util.HashMap; > import java.util.Hashtable; > import java.util.Iterator; > -import java.util.List; > import java.util.Map; > import java.util.Vector; > import java.util.concurrent.ConcurrentHashMap; > @@ -142,14 +140,19 @@ > initEventQueue(panel); > > // Wait for panel to come alive > - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > - int wait = 0; > - while (!panel.isAlive() && wait < maxWait) { > - try { > - Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > + // Wait implemented the long way so that > + // PluginAppletViewer.waitTillTimeout() needn't be exposed. > + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > + > + synchronized(panel) { > + while (!panel.isAlive() && maxTimeToSleep > 0) { > + long sleepStart = System.currentTimeMillis(); > + > + try { > + panel.wait(maxTimeToSleep); > + } catch (InterruptedException e) {} // Just loop back > + > + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); So this one matches src.wait() below? It's a little unclear due to the differing variable names. Is there a reason why this doesn't use waitTillTimeout? > } > } > > @@ -307,6 +310,10 @@ > panel.addAppletListener(appletFrame.appletEventListener); > > applets.put(identifier, appletFrame); > + > + synchronized(applets) { > + applets.notifyAll(); > + } > > PluginDebug.debug(panel, " framed"); > } This change is correct, but I'm a bit dubious about having one set of locks in the CHM for the put and our own lock on applets here. Maybe revert back to HashMaps and handle all locking in one place? > @@ -357,6 +364,10 @@ > public void appletStateChanged(AppletEvent evt) { > AppletPanel src = (AppletPanel) evt.getSource(); > > + synchronized (src) { > + src.notifyAll(); > + } > + > switch (evt.getID()) { > case AppletPanel.APPLET_RESIZE: { > if (src != null) { > @@ -448,21 +459,16 @@ > new StringReader(tag), > new URL(documentBase)); > > - int maxWait = APPLET_TIMEOUT; // wait for applet to fully load > - int wait = 0; > - while (!applets.containsKey(identifier) && // Map is populated only by reFrame > - (wait < maxWait)) { > - > - try { > - Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > + long maxTimeToSleep = APPLET_TIMEOUT; > + synchronized(applets) { > + while (!applets.containsKey(identifier) && > + maxTimeToSleep > 0) { // Map is populated only by reFrame > + maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); > } > } > > // If wait exceeded maxWait, we timed out. Throw an exception > - if (wait >= maxWait) > + if (maxTimeToSleep <= 0) > throw new Exception("Applet initialization timeout"); > > // We should not try to destroy an applet during > @@ -547,6 +553,10 @@ > > // Else set to given status > status.put(identifier, newStatus); > + > + synchronized(status) { > + status.notifyAll(); > + } > Similar comment as above. > return prev; > } > @@ -599,7 +609,9 @@ > } > > /** > - * Function to block until applet initialization is complete > + * Function to block until applet initialization is complete. > + * > + * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} > * > * @param panel the instance to wait for. > */ > @@ -608,16 +620,14 @@ > int waitTime = 0; > > // Wait till initialization finishes > - while (panel.getApplet() == null && > - panel.isAlive() && > - waitTime < APPLET_TIMEOUT) { > - try { > - if (waitTime % 500 == 0) > - PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); > + long maxTimeToSleep = APPLET_TIMEOUT; > > - Thread.sleep(waitTime += 50); > - } catch (InterruptedException ie) { > - // just wait > + synchronized(panel) { > + while (panel.getApplet() == null && > + panel.isAlive() && > + maxTimeToSleep > 0) { > + PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); > + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > } > } > > @@ -628,14 +638,11 @@ > if (message.startsWith("width")) { > > // Wait for panel to come alive > - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive > - int wait = 0; > - while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && wait < maxWait) { > - try { > - Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > + int maxTimeToSleep = APPLET_TIMEOUT; > + synchronized(status) { > + while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && > + maxTimeToSleep > 0) { > + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); Is status guaranteed to contain a mapping for identifier? > } > } > > @@ -686,17 +693,21 @@ > // FIXME: how do we determine what security context this > // object should belong to? > Object o; > - > - // Wait for panel to come alive > - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive > - int wait = 0; > - while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { > + > + // First, wait for panel to instantiate > + int waited = 0; > + while (panel == null && waited < APPLET_TIMEOUT) { > try { > Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > - } > + waited += 50; > + } catch (InterruptedException ie) {} // discard, loop back > + } > + > + // Next, wait for panel to come alive > + long maxTimeToSleep = APPLET_TIMEOUT; > + synchronized(panel) { > + while (!panel.isAlive()) > + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); I presume panel is global to this instance? Maybe we should introduce something else to provide the conditional wait so you don't need this split between the null/sleep(50) loop and the initialising/notification loop. > } > > // Wait for the panel to initialize > @@ -2049,4 +2060,36 @@ > // Draw the painted image > g.drawImage(bufFrameImg, 0, 0, this); > } > + > + /** > + * Waits on a given object until timeout. > + * > + * This function assumes that the monitor lock has already been > + * acquired by the caller. > + * > + * If the given object is null, this function returns immediately. > + * > + * @param obj The object to wait on > + * @param timeout The maximum time to wait > + * @return Approximate time spent sleeping (not guaranteed to be perfect) > + */ > + public static long waitTillTimeout(Object obj, long timeout) { > + > + // Can't wait on null. Return 0 indicating no wait happened. > + if (obj == null) > + return 0; > + > + // Record when we started sleeping > + long sleepStart = System.currentTimeMillis(); > + > + try { > + obj.wait(timeout); > + } catch (InterruptedException ie) {} // Discarded, time to return > + > + // Record when we woke up > + long sleepEnd = System.currentTimeMillis(); > + > + // Return the difference > + return sleepEnd - sleepStart; > + } Would have been nice to have closures for this. Then you could pass the condition to this method, and have the whole block handled here. :-) > } -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 14 04:41:44 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 12:41:44 +0100 Subject: [RFC][Icedtea-Web]: make CacheDirectory class final In-Reply-To: <20110413211206.GG28506@redhat.com> References: <437316425.78339.1302724877207.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <312983582.78818.1302726207842.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <20110413211206.GG28506@redhat.com> Message-ID: <20110414114144.GD7262@rivendell.middle-earth.co.uk> On 17:12 Wed 13 Apr , Deepak Bhole wrote: > * Andrew Su [2011-04-13 16:24]: > > Seems like this email didn't make it back to my inbox.. Resending. > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013566.html > > > > Okay for head. > +1 here too. > Deepak > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 14 04:45:32 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 12:45:32 +0100 Subject: PING [icedtea-web] RFC: Add additional lookup location for JUnit4 jar In-Reply-To: <20110411154841.GC13424@rivendell.middle-earth.co.uk> References: <20110411154841.GC13424@rivendell.middle-earth.co.uk> Message-ID: <20110414114532.GE7262@rivendell.middle-earth.co.uk> PING? Guess this one didn't get through either on Monday. On 16:48 Mon 11 Apr , Dr Andrew John Hughes wrote: > JUnit is installed in /usr/share/junit-4/lib/junit.jar on Gentoo systems. > The attached patch adds this location to those searched for JUnit 4. > > Ok for HEAD? > > 2010-04-11 Andrew John Hughes > > * configure.ac: > Check Gentoo install location for JUnit 4. > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > diff -r 934543b8084d configure.ac > --- a/configure.ac Mon Apr 11 16:03:44 2011 +0100 > +++ b/configure.ac Mon Apr 11 16:39:08 2011 +0100 > @@ -86,7 +86,7 @@ > IT_FIND_OPTIONAL_JAR([rhino], RHINO, > [/usr/share/java/js.jar /usr/share/rhino-1.6/lib/js.jar]) > IT_FIND_OPTIONAL_JAR([junit], JUNIT, > - [/usr/share/java/junit4.jar]) > + [/usr/share/java/junit4.jar /usr/share/junit-4/lib/junit.jar]) > > AC_CONFIG_FILES([jrunscript], [chmod u+x jrunscript]) > AC_CONFIG_FILES([build.properties]) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 14 04:58:26 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 12:58:26 +0100 Subject: Fwd: Re: adding testng after removig of junit In-Reply-To: <4DA492E5.7050200@redhat.com> References: <4DA492E5.7050200@redhat.com> Message-ID: <20110414115826.GF7262@rivendell.middle-earth.co.uk> On 19:59 Tue 12 Apr , Jiri Vanek wrote: snip... > > > > In brief: > > > > * With the current solution, we can directly produce the JTreg-like > > output we want via our subclass and already do. From what I > > understand of the TestNG patch, it would produce XML and then we'd > > have to convert it. Exactly why is that better? > > Because we DO NOT want jtreg like result. Who is 'we'? If you've read the previous discussion, you'll know that JTreg output was stated as a requirement so that the test suite worked well with the build bots. > Pavel is doing magic to create > reports as are now from such a bad output. From xml - we have all > informations. Pavel will use it to produce reports containing stack > traces, will be able to see directly which ones should fail and which > should pass. Will be able to separate groups,Will be able to create very > solid statistics, and whatever we can imagine. It is pitty to lost all > the information. jtreg-like is just poor summary - and without ant it is > probably impossible to reach something better. You make a lot of unsubstantiated claims here. If you want different output, you are welcome to submit a different outputter along the lines of the one Omair wrote for jtreg output and provide a way of using that instead. > > Another advance is extreme configurability (see bottom). > What is 'extreme configurability' and why would we want it? > > > > > * Switching to TestNG also adds a mass of dependencies which aren't > > needed with JUnit, making it harder for people to run the test suite. > > > > testng are three jars. Junit is one jar. I do not see difference whether > wee need to make special steps to add one jar to classpath or three. Al > four of them are easily to be found and downloaded. And all are packaged > in fedora (an in most of distros). Under what licenses? This discussion is the first I've heard of TestNG and the support for it in various distros seems to be immature. In comparison, JUnit is well-established and without extraneous dependencies. > > > Unless you can produce a clear example of why switching to TestNG > > for IcedTea-Web is essential and which overrides the need for all > > those additional dependencies, I see no reason to drop a solution that > > works and has already been extensively reviewed. > > > > What I see essential is output of test framework and configureability. > junit is not about to be run from commadline. Of course it can be run from the command line. We're doing it right now. > It is ant tool. No it isn't. > And we do > not want ant for sure (we have make). > You will probably never use or run this test. Me, Pavel and Omair will > do it most of time. This is a FOSS project. You can't make assumptions about who will run the tests. Distros, for example, will want to run these tests to verify that IcedTea-Web has built and installed correctly. Having less dependencies makes this easier. Clearly you can't give a clear example of why TestNG is so much better and have to resort to cheap personal attacks instead. And for myself i really wont to configure what i'm > running. This Luncher class and makefile "send all classes to classpath" > is dreadfull hack. > > Btw.. I have already posted all of those dis/advantages;) > >> J. > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From jvanek at redhat.com Thu Apr 14 05:24:01 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 14 Apr 2011 14:24:01 +0200 Subject: Fwd: Re: adding testng after removig of junit In-Reply-To: <20110414115826.GF7262@rivendell.middle-earth.co.uk> References: <4DA492E5.7050200@redhat.com> <20110414115826.GF7262@rivendell.middle-earth.co.uk> Message-ID: <4DA6E761.2010204@redhat.com> On 04/14/2011 01:58 PM, Dr Andrew John Hughes wrote: > On 19:59 Tue 12 Apr , Jiri Vanek wrote: > > snip... > This is still the same arround:( >>> >>> In brief: >>> >>> * With the current solution, we can directly produce the JTreg-like >>> output we want via our subclass and already do. From what I >>> understand of the TestNG patch, it would produce XML and then we'd >>> have to convert it. Exactly why is that better? >> >> Because we DO NOT want jtreg like result. > > Who is 'we'? If you've read the previous discussion, you'll know that > JTreg output was stated as a requirement so that the test suite worked > well with the build bots. We == everybody who will USE this testsuite. JTreg output is Minimal requirement. But for JUnit it probably also Maximal. You didn't get it. TestNG output is execlent. Why to avoid all those benefits or to write (maybe) complicated class and invent wheel again? > >> Pavel is doing magic to create >> reports as are now from such a bad output. From xml - we have all >> informations. Pavel will use it to produce reports containing stack >> traces, will be able to see directly which ones should fail and which >> should pass. Will be able to separate groups,Will be able to create very >> solid statistics, and whatever we can imagine. It is pitty to lost all >> the information. jtreg-like is just poor summary - and without ant it is >> probably impossible to reach something better. > > You make a lot of unsubstantiated claims here. If you want different output, > you are welcome to submit a different outputter along the lines of the one > Omair wrote for jtreg output and provide a way of using that instead. This luncher and listener classes are disgusting. (Nothing against Omair's code, but against concept). It is unclear for everybody who will be looking inside project. And I'm afraid it cause troubles. > >> >> Another advance is extreme configurability (see bottom). >> > > What is 'extreme configurability' and why would we want it? Why to ecape solution which have it? You can easily group tests, run just some subset of test, exlude tests, specific order of tests... And it is clearly to be seen in XML - in comparsion with make file find *.class mess. Which I consider really unsuitable, and can't believe it pass review. > >> >>> >>> * Switching to TestNG also adds a mass of dependencies which aren't >>> needed with JUnit, making it harder for people to run the test suite. >>> >> >> testng are three jars. Junit is one jar. I do not see difference whether >> wee need to make special steps to add one jar to classpath or three. Al >> four of them are easily to be found and downloaded. And all are packaged >> in fedora (an in most of distros). > > Under what licenses? This discussion is the first I've heard of TestNG > and the support for it in various distros seems to be immature. In comparison, > JUnit is well-established and without extraneous dependencies. > It is under appache licence which is much more suitable for FSOS/any project then Common Public License. Even when some distro have missing some of those three libraries (which I do not believe as they are widely used libraries), then it is just benefit for them to add it - or just downlood jars and use them on classpath. >> >>> Unless you can produce a clear example of why switching to TestNG >>> for IcedTea-Web is essential and which overrides the need for all >>> those additional dependencies, I see no reason to drop a solution that >>> works and has already been extensively reviewed. >>> >> >> What I see essential is output of test framework and configureability. >> junit is not about to be run from commadline. > > Of course it can be run from the command line. We're doing it right now. > Not exactly. We had to create class luncher for it, and makefile execution is disaster. >> It is ant tool. > > No it isn't. > >> And we do >> not want ant for sure (we have make). >> You will probably never use or run this test. Me, Pavel and Omair will >> do it most of time. > > This is a FOSS project. You can't make assumptions about who will run the > tests. Distros, for example, will want to run these tests to verify that > IcedTea-Web has built and installed correctly. Having less dependencies > makes this easier. > One jar or three? > Clearly you can't give a clear example of why TestNG is so much better and > have to resort to cheap personal attacks instead. > Please don't tkae it personaly. I suspect you from seeing it from make/distros perspective. I see it from .. "java developer: point of view. > And for myself i really wont to configure what i'm >> running. This Luncher class and makefile "send all classes to classpath" >> is dreadfull hack. >> >> Btw.. I have already posted all of those dis/advantages;) >>>> J. >>> >> >> > > > Regards J. From bugzilla-daemon at icedtea.classpath.org Thu Apr 14 06:06:20 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 14 Apr 2011 13:06:20 +0000 Subject: [Bug 692] New: africanking at win2day.at does not work Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=692 Summary: africanking at win2day.at does not work Product: IcedTea-Web Version: 1.0.2 Platform: all URL: https://www.win2day.at/ OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Plugin AssignedTo: dbhole at redhat.com ReportedBy: mvyskocil at suse.cz CC: unassigned at icedtea.classpath.org Created an attachment (id=513) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=513) plugin debug output The games from win2day.at are not working in icedtea-web 1.0.2 (icedtea6-1.10.1/openjdkb22). How to reproduce, Go to "Casino Spiele" -> Slots -> "African King" (or any java game from slots). Then accept a certificate and after few seconds the green loading screen disappear. The debug output of plugin is attached. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From dbhole at redhat.com Thu Apr 14 06:22:02 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 09:22:02 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414114100.GC7262@rivendell.middle-earth.co.uk> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <20110414114100.GC7262@rivendell.middle-earth.co.uk> Message-ID: <20110414132202.GA32038@redhat.com> * Dr Andrew John Hughes [2011-04-14 07:41]: > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > * Deepak Bhole [2011-04-13 20:48]: > > > Hi, > > > > > > Andrew mentioned in one of the previous threads that the current plugin > > > code waits in an inefficient manner. It wakes up periodically to > > > check for conditions, and goes back to sleep, and keeps doing that > > > cyclically. > > > > > > The attached patch uses a new function that uses object.wait for > > > the object of interest. > > > > > > > Please see attached new patch. After leaving the office I realized that > > there is a potential race condition in the old patch with locking the > > object inside the wait function. Patch updated to do the locking > > outside (and function comment updated to clearly state that). > > > > Can you elaborate? If it's the same thread acquiring the lock in both > cases, then it should be fine as they are re-entrant i.e. if the function > attempts to lock it and the thread already holds the lock, it's a no-op. > Before, the locking was inside the function, like so: while ! waitTillTimeout(OBJ, timeout) ... ... function ... waitTillTimeout(OBJ, timeout) { lock (OBJ) OBJ.wait() ... } The problem was that condition on OBJ could've been false at check, but then become true before waitTillTimeout() was called. This would result in an incorrect wait until timeout. By moving the lock to before condition checking, the code guarantees that waiting is done only if needed. As I wrote this, I realized that in order for the above to work, we would have to lock the hashmap on update too since CHM's locking works differently and may not lock the full table. I will post a separate patch in a bit with the change. In the mean time, I have replied to other concerns below. > > Cheers, > > Deepak > > Comments inline. As Jiri said, a ChangeLog would be good too. > Oops, sorry I should've mentioned, the ChangeLog is the same as before (only the locking area changed). Here it is: 2011-04-13 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (createPanel): use Object.wait() to wait, rather than pariodic sleep. (framePanel): Notify threads waiting on the applets map instance. (appletStateChanged): Notify all threads waiting on the panel that just changed state. (handleMessage): Use the new waitTillTimeout function to wait, rather than periodically waking up. (updateStatus): Notify all threads waiting on status map. (waitForAppletInit): Use the new waitTillTimeout function to wait, rather than periodically waking up. (waitTillTimeout): New function. For a given non-null object, waits until the specified timeout, or, if an interrupt was thrown during wait, returns immediately. > > - // just wait > > + // Wait implemented the long way so that > > + // PluginAppletViewer.waitTillTimeout() needn't be exposed. > > + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > > + > > + synchronized(panel) { > > + while (!panel.isAlive() && maxTimeToSleep > 0) { > > + long sleepStart = System.currentTimeMillis(); > > + > > + try { > > + panel.wait(maxTimeToSleep); > > + } catch (InterruptedException e) {} // Just loop back > > + > > + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); > > So this one matches src.wait() below? It's a little unclear due to the differing > variable names. > > Is there a reason why this doesn't use waitTillTimeout? > I mentioned it in the comments, it is so that PluginAppletViewer.waitTillTimeout() could remain private (the above is in a separate class). I intend to re-factor a lot of that code (already started working on it yesterday) that will address it there. In the mean time, I saw no harm in duplicating a few lines of code. > > } > > } > > > > @@ -307,6 +310,10 @@ > > panel.addAppletListener(appletFrame.appletEventListener); > > > > applets.put(identifier, appletFrame); > > + > > + synchronized(applets) { > > + applets.notifyAll(); > > + } > > > > PluginDebug.debug(panel, " framed"); > > } > > This change is correct, but I'm a bit dubious about having one set of > locks in the CHM for the put and our own lock on applets here. Maybe > revert back to HashMaps and handle all locking in one place? > We would then have to lock on all gets too. CHMs locking is more efficient as it locks on only parts of the table. That is why I chose to do locking only around code that needs it (the API requires wait and notifyall to be calls from threads that own the monitor lock). > > - } catch (InterruptedException ie) { > > - // just wait > > + int maxTimeToSleep = APPLET_TIMEOUT; > > + synchronized(status) { > > + while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && > > + maxTimeToSleep > 0) { > > + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); > > Is status guaranteed to contain a mapping for identifier? > Yes, it is. > > } > > } > > > > @@ -686,17 +693,21 @@ > > // FIXME: how do we determine what security context this > > // object should belong to? > > Object o; > > - > > - // Wait for panel to come alive > > - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive > > - int wait = 0; > > - while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { > > + > > + // First, wait for panel to instantiate > > + int waited = 0; > > + while (panel == null && waited < APPLET_TIMEOUT) { > > try { > > Thread.sleep(50); > > - wait += 50; > > - } catch (InterruptedException ie) { > > - // just wait > > - } > > + waited += 50; > > + } catch (InterruptedException ie) {} // discard, loop back > > + } > > + > > + // Next, wait for panel to come alive > > + long maxTimeToSleep = APPLET_TIMEOUT; > > + synchronized(panel) { > > + while (!panel.isAlive()) > > + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > > I presume panel is global to this instance? > > Maybe we should introduce something else to provide the conditional wait so you > don't need this split between the null/sleep(50) loop and the initialising/notification loop. > Yeah I wasn't too happy about having to keep the above. I thought about introducing an additional lock for the object, but the truth is that the sleep will happen for a very short time, if it ever does. Furthermore, the above would get called only for liveconnect based applets, so it didn't seem worth it. I can still do it if you prefer though. > > Would have been nice to have closures for this. Then you could pass the condition > to this method, and have the whole block handled here. :-) > Only 20 more months if all goes well! :) Cheers, Deepak > > } > > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Thu Apr 14 06:23:23 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 09:23:23 -0400 Subject: PING [icedtea-web] RFC: Add additional lookup location for JUnit4 jar In-Reply-To: <20110414114532.GE7262@rivendell.middle-earth.co.uk> References: <20110411154841.GC13424@rivendell.middle-earth.co.uk> <20110414114532.GE7262@rivendell.middle-earth.co.uk> Message-ID: <20110414132323.GB32038@redhat.com> * Dr Andrew John Hughes [2011-04-14 07:46]: > PING? Guess this one didn't get through either on Monday. > > On 16:48 Mon 11 Apr , Dr Andrew John Hughes wrote: > > JUnit is installed in /usr/share/junit-4/lib/junit.jar on Gentoo systems. > > The attached patch adds this location to those searched for JUnit 4. > > > > Ok for HEAD? > > > > 2010-04-11 Andrew John Hughes > > > > * configure.ac: > > Check Gentoo install location for JUnit 4. I thought Gentoo used jpackage style locations too.. guess not. Anyway, looks good to me. Okay for head. Cheers, Deepak > > -- > > Andrew :) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and IcedTea > > http://www.gnu.org/software/classpath > > http://icedtea.classpath.org > > PGP Key: F5862A37 (https://keys.indymedia.org/) > > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > > > diff -r 934543b8084d configure.ac > > --- a/configure.ac Mon Apr 11 16:03:44 2011 +0100 > > +++ b/configure.ac Mon Apr 11 16:39:08 2011 +0100 > > @@ -86,7 +86,7 @@ > > IT_FIND_OPTIONAL_JAR([rhino], RHINO, > > [/usr/share/java/js.jar /usr/share/rhino-1.6/lib/js.jar]) > > IT_FIND_OPTIONAL_JAR([junit], JUNIT, > > - [/usr/share/java/junit4.jar]) > > + [/usr/share/java/junit4.jar /usr/share/junit-4/lib/junit.jar]) > > > > AC_CONFIG_FILES([jrunscript], [chmod u+x jrunscript]) > > AC_CONFIG_FILES([build.properties]) > > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at redhat.com Thu Apr 14 06:45:04 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 09:45:04 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110413211035.GF28506@redhat.com> Message-ID: <1094442283.290176.1302788704839.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Instead of doing this, it would be easier to change the type of > appletPanels to Vector , then the casting is not > needed as AVP inherits from AP. The casting to AppletViewerPanel is not caused by appletPanels. It is caused by the "panel" member. It used to be declared as an AVP, then I changed it to a NetxPanel, which made the 3 new casts necessary (but it eliminated many more casts than it added). That said, I wouldn't mind changing the type of appletPanels to Vector. Do you still think I should? Thank you, Denis. ----- Original Message ----- > * Denis Lila [2011-04-13 15:10]: > > > If a patch akin to > > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > > goes in, I will not be responsible for my actions. > > > > I definitely don't want that ;-). > > > > Attached is the second patch. It's mostly cleanup, and it > > also uses "pav" in destroyApplet, instead of calling > > get(id) again and again. > > > > Ok to push? > > > > ... > ... > > > > > > PluginDebug.debug("getCachedImageRef() getting img from > > URL = ", url); > > @@ -910,8 +815,8 @@ > > SocketPermission panelSp = > > new SocketPermission(panel.getCodeBase().getHost(), > > "connect"); > > synchronized(appletPanels) { > > - for (Enumeration e = appletPanels.elements(); > > e.hasMoreElements();) { > > - AppletPanel p = (AppletPanel) e.nextElement(); > > + for (Enumeration e = appletPanels.elements(); > > e.hasMoreElements();) { > > + AppletPanel p = e.nextElement(); > > String param = p.getParameter("name"); > > if (param != null) { > > param = param.toLowerCase(); > > @@ -1591,15 +1496,15 @@ > > * at the same time. > > */ > > try { > > - panel.joinAppletThread(); > > - panel.release(); > > + ((AppletViewerPanel)panel).joinAppletThread(); > > + ((AppletViewerPanel)panel).release(); > > } catch (InterruptedException e) { > > return; // abort the reload > > } > > > > AccessController.doPrivileged(new PrivilegedAction() > > { > > public Void run() { > > - panel.createAppletThread(); > > + ((AppletViewerPanel)panel).createAppletThread(); > > return null; > > } > > From ahughes at redhat.com Thu Apr 14 06:48:42 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 14:48:42 +0100 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1094442283.290176.1302788704839.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110413211035.GF28506@redhat.com> <1094442283.290176.1302788704839.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414134842.GG7262@rivendell.middle-earth.co.uk> On 09:45 Thu 14 Apr , Denis Lila wrote: > > Instead of doing this, it would be easier to change the type of > > appletPanels to Vector , then the casting is not > > needed as AVP inherits from AP. > > The casting to AppletViewerPanel is not caused by appletPanels. It > is caused by the "panel" member. It used to be declared as an AVP, > then I changed it to a NetxPanel, which made the 3 new casts > necessary (but it eliminated many more casts than it added). > > That said, I wouldn't mind changing the type of appletPanels > to Vector. Do you still think I should? > Does it only ever store AVPs? And, most importantly, are there casts which assume AVPs are stored there? If only the former is true, it would strengthen the type requirements of the collection to a specific subtype so you must be sure that's what you want and that you don't ever want to store a different subtype or instances of the more general type. > Thank you, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-13 15:10]: > > > > If a patch akin to > > > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > > > goes in, I will not be responsible for my actions. > > > > > > I definitely don't want that ;-). > > > > > > Attached is the second patch. It's mostly cleanup, and it > > > also uses "pav" in destroyApplet, instead of calling > > > get(id) again and again. > > > > > > Ok to push? > > > > > > > ... > > ... > > > > > > > > > > PluginDebug.debug("getCachedImageRef() getting img from > > > URL = ", url); > > > @@ -910,8 +815,8 @@ > > > SocketPermission panelSp = > > > new SocketPermission(panel.getCodeBase().getHost(), > > > "connect"); > > > synchronized(appletPanels) { > > > - for (Enumeration e = appletPanels.elements(); > > > e.hasMoreElements();) { > > > - AppletPanel p = (AppletPanel) e.nextElement(); > > > + for (Enumeration e = appletPanels.elements(); > > > e.hasMoreElements();) { > > > + AppletPanel p = e.nextElement(); > > > String param = p.getParameter("name"); > > > if (param != null) { > > > param = param.toLowerCase(); > > > @@ -1591,15 +1496,15 @@ > > > * at the same time. > > > */ > > > try { > > > - panel.joinAppletThread(); > > > - panel.release(); > > > + ((AppletViewerPanel)panel).joinAppletThread(); > > > + ((AppletViewerPanel)panel).release(); > > > } catch (InterruptedException e) { > > > return; // abort the reload > > > } > > > > > > AccessController.doPrivileged(new PrivilegedAction() > > > { > > > public Void run() { > > > - panel.createAppletThread(); > > > + ((AppletViewerPanel)panel).createAppletThread(); > > > return null; > > > } > > > > > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Thu Apr 14 06:57:10 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 09:57:10 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1094442283.290176.1302788704839.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110413211035.GF28506@redhat.com> <1094442283.290176.1302788704839.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414135710.GA727@redhat.com> * Denis Lila [2011-04-14 09:45]: > > Instead of doing this, it would be easier to change the type of > > appletPanels to Vector , then the casting is not > > needed as AVP inherits from AP. > > The casting to AppletViewerPanel is not caused by appletPanels. It > is caused by the "panel" member. It used to be declared as an AVP, > then I changed it to a NetxPanel, which made the 3 new casts > necessary (but it eliminated many more casts than it added). > NetxPanel inherits from AVP, so why is the cast needed? Does NetxPanel override the method? > That said, I wouldn't mind changing the type of appletPanels > to Vector. Do you still think I should? > Actually, perhaps we should go one step up and just change it to NetxPanel? We only store those in the vector anyway. Cheers, Deepak > Thank you, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-13 15:10]: > > > > If a patch akin to > > > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > > > goes in, I will not be responsible for my actions. > > > > > > I definitely don't want that ;-). > > > > > > Attached is the second patch. It's mostly cleanup, and it > > > also uses "pav" in destroyApplet, instead of calling > > > get(id) again and again. > > > > > > Ok to push? > > > > > > > ... > > ... > > > > > > > > > > PluginDebug.debug("getCachedImageRef() getting img from > > > URL = ", url); > > > @@ -910,8 +815,8 @@ > > > SocketPermission panelSp = > > > new SocketPermission(panel.getCodeBase().getHost(), > > > "connect"); > > > synchronized(appletPanels) { > > > - for (Enumeration e = appletPanels.elements(); > > > e.hasMoreElements();) { > > > - AppletPanel p = (AppletPanel) e.nextElement(); > > > + for (Enumeration e = appletPanels.elements(); > > > e.hasMoreElements();) { > > > + AppletPanel p = e.nextElement(); > > > String param = p.getParameter("name"); > > > if (param != null) { > > > param = param.toLowerCase(); > > > @@ -1591,15 +1496,15 @@ > > > * at the same time. > > > */ > > > try { > > > - panel.joinAppletThread(); > > > - panel.release(); > > > + ((AppletViewerPanel)panel).joinAppletThread(); > > > + ((AppletViewerPanel)panel).release(); > > > } catch (InterruptedException e) { > > > return; // abort the reload > > > } > > > > > > AccessController.doPrivileged(new PrivilegedAction() > > > { > > > public Void run() { > > > - panel.createAppletThread(); > > > + ((AppletViewerPanel)panel).createAppletThread(); > > > return null; > > > } > > > > > From dlila at redhat.com Thu Apr 14 07:01:15 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 10:01:15 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110414134842.GG7262@rivendell.middle-earth.co.uk> Message-ID: <939595708.294635.1302789675739.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Does it only ever store AVPs? It only ever stores NetxPanels which is a descendant of AVP. > And, most importantly, are there casts which assume AVPs > are stored there? There are no casts associated with this vector at all (except the invisible ones necessitated by type erasure of generics). > If only the former is true, it would strengthen the type requirements > of the collection to a specific subtype so you must be sure that's > what you want and that you don't ever want to store a different > subtype or instances of the more general type. That's true. Even though the vector only contains NetxPanels, I see no reason to make that a requirement by changing the type. We only use it for the "applet" field of it's elements, and Vector is enough for us to get that field. Regards, Denis. ----- Original Message ----- > On 09:45 Thu 14 Apr , Denis Lila wrote: > > > Instead of doing this, it would be easier to change the type of > > > appletPanels to Vector , then the casting is > > > not > > > needed as AVP inherits from AP. > > > > The casting to AppletViewerPanel is not caused by appletPanels. It > > is caused by the "panel" member. It used to be declared as an AVP, > > then I changed it to a NetxPanel, which made the 3 new casts > > necessary (but it eliminated many more casts than it added). > > > > That said, I wouldn't mind changing the type of appletPanels > > to Vector. Do you still think I should? > > > > > > > Thank you, > > Denis. > > > > ----- Original Message ----- > > > * Denis Lila [2011-04-13 15:10]: > > > > > If a patch akin to > > > > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > > > > goes in, I will not be responsible for my actions. > > > > > > > > I definitely don't want that ;-). > > > > > > > > Attached is the second patch. It's mostly cleanup, and it > > > > also uses "pav" in destroyApplet, instead of calling > > > > get(id) again and again. > > > > > > > > Ok to push? > > > > > > > > > > ... > > > ... > > > > > > > > > > > > > > PluginDebug.debug("getCachedImageRef() getting img > > > > from > > > > URL = ", url); > > > > @@ -910,8 +815,8 @@ > > > > SocketPermission panelSp = > > > > new > > > > SocketPermission(panel.getCodeBase().getHost(), > > > > "connect"); > > > > synchronized(appletPanels) { > > > > - for (Enumeration e = appletPanels.elements(); > > > > e.hasMoreElements();) { > > > > - AppletPanel p = (AppletPanel) e.nextElement(); > > > > + for (Enumeration e = appletPanels.elements(); > > > > e.hasMoreElements();) { > > > > + AppletPanel p = e.nextElement(); > > > > String param = p.getParameter("name"); > > > > if (param != null) { > > > > param = param.toLowerCase(); > > > > @@ -1591,15 +1496,15 @@ > > > > * at the same time. > > > > */ > > > > try { > > > > - panel.joinAppletThread(); > > > > - panel.release(); > > > > + ((AppletViewerPanel)panel).joinAppletThread(); > > > > + ((AppletViewerPanel)panel).release(); > > > > } catch (InterruptedException e) { > > > > return; // abort the reload > > > > } > > > > > > > > AccessController.doPrivileged(new > > > > PrivilegedAction() > > > > { > > > > public Void run() { > > > > - panel.createAppletThread(); > > > > + ((AppletViewerPanel)panel).createAppletThread(); > > > > return null; > > > > } > > > > > > > > > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at redhat.com Thu Apr 14 07:07:42 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 10:07:42 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110414135710.GA727@redhat.com> Message-ID: <353707308.295851.1302790062753.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > NetxPanel inherits from AVP, so why is the cast needed? Does NetxPanel > override the method? Yes, NetxPanel overrides the 3 methods that we need the casts for. Since they're protected, but NetxPanel is in a different package, the compiler gives an error. > > That said, I wouldn't mind changing the type of appletPanels > > to Vector. Do you still think I should? > > > > Actually, perhaps we should go one step up and just change it to > NetxPanel? We only store those in the vector anyway. We could, but I would rather not because we only use that vector for the "applet" field of the AppletPanel class. We don't need a NetxPanel for that. Using a NetxPanel would add irrelevant details. Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-14 09:45]: > > > Instead of doing this, it would be easier to change the type of > > > appletPanels to Vector , then the casting is > > > not > > > needed as AVP inherits from AP. > > > > The casting to AppletViewerPanel is not caused by appletPanels. It > > is caused by the "panel" member. It used to be declared as an AVP, > > then I changed it to a NetxPanel, which made the 3 new casts > > necessary (but it eliminated many more casts than it added). > > > > > > Cheers, > Deepak > > > Thank you, > > Denis. > > > > ----- Original Message ----- > > > * Denis Lila [2011-04-13 15:10]: > > > > > If a patch akin to > > > > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > > > > goes in, I will not be responsible for my actions. > > > > > > > > I definitely don't want that ;-). > > > > > > > > Attached is the second patch. It's mostly cleanup, and it > > > > also uses "pav" in destroyApplet, instead of calling > > > > get(id) again and again. > > > > > > > > Ok to push? > > > > > > > > > > ... > > > ... > > > > > > > > > > > > > > PluginDebug.debug("getCachedImageRef() getting img > > > > from > > > > URL = ", url); > > > > @@ -910,8 +815,8 @@ > > > > SocketPermission panelSp = > > > > new > > > > SocketPermission(panel.getCodeBase().getHost(), > > > > "connect"); > > > > synchronized(appletPanels) { > > > > - for (Enumeration e = appletPanels.elements(); > > > > e.hasMoreElements();) { > > > > - AppletPanel p = (AppletPanel) e.nextElement(); > > > > + for (Enumeration e = appletPanels.elements(); > > > > e.hasMoreElements();) { > > > > + AppletPanel p = e.nextElement(); > > > > String param = p.getParameter("name"); > > > > if (param != null) { > > > > param = param.toLowerCase(); > > > > @@ -1591,15 +1496,15 @@ > > > > * at the same time. > > > > */ > > > > try { > > > > - panel.joinAppletThread(); > > > > - panel.release(); > > > > + ((AppletViewerPanel)panel).joinAppletThread(); > > > > + ((AppletViewerPanel)panel).release(); > > > > } catch (InterruptedException e) { > > > > return; // abort the reload > > > > } > > > > > > > > AccessController.doPrivileged(new > > > > PrivilegedAction() > > > > { > > > > public Void run() { > > > > - panel.createAppletThread(); > > > > + ((AppletViewerPanel)panel).createAppletThread(); > > > > return null; > > > > } > > > > > > > > From omajid at redhat.com Thu Apr 14 07:56:16 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Apr 2011 10:56:16 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414055656.GA18391@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> Message-ID: <4DA70B10.4030801@redhat.com> On 04/14/2011 01:56 AM, Deepak Bhole wrote: > * Deepak Bhole [2011-04-13 20:48]: >> > Hi, >> > >> > Andrew mentioned in one of the previous threads that the current plugin >> > code waits in an inefficient manner. It wakes up periodically to >> > check for conditions, and goes back to sleep, and keeps doing that >> > cyclically. >> > >> > The attached patch uses a new function that uses object.wait for >> > the object of interest. >> > > Please see attached new patch. After leaving the office I realized that > there is a potential race condition in the old patch with locking the > object inside the wait function. Patch updated to do the locking > outside (and function comment updated to clearly state that). > > Cheers, > Deepak > > > wait-fixes.patch > > > diff -r 2ef65ff10619 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 19:17:21 2011 -0400 > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 01:54:04 2011 -0400 > @@ -91,12 +91,10 @@ > import java.security.PrivilegedAction; > import java.security.PrivilegedActionException; > import java.security.PrivilegedExceptionAction; > -import java.util.ArrayList; > import java.util.Enumeration; > import java.util.HashMap; > import java.util.Hashtable; > import java.util.Iterator; > -import java.util.List; > import java.util.Map; > import java.util.Vector; > import java.util.concurrent.ConcurrentHashMap; > @@ -142,14 +140,19 @@ > initEventQueue(panel); > > // Wait for panel to come alive > - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > - int wait = 0; > - while (!panel.isAlive()&& wait< maxWait) { > - try { > - Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > + // Wait implemented the long way so that > + // PluginAppletViewer.waitTillTimeout() needn't be exposed. > + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > + > + synchronized(panel) { > + while (!panel.isAlive()&& maxTimeToSleep> 0) { > + long sleepStart = System.currentTimeMillis(); > + > + try { > + panel.wait(maxTimeToSleep); > + } catch (InterruptedException e) {} // Just loop back > + > + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); Can you not use waitTillTimeout here? Also, perhaps we should be using System.nanoTime() instead of System.currentTimeMillis(). Using System.currenTimeMillis() relies on the assumption that the user's clock does not change. If a daylight savings change happens to kick in, or the computer's clock is updated (say, based on NTP), then the results of currentTimeMillis() can be quite disastrous (especially if the clock moved backwards). System.nanoTime() uses clock_gettime(CLOCK_MONOTONIC) (where supported) so it should be safe from any changes in the clock. Thanks, Omair From dbhole at redhat.com Thu Apr 14 07:59:58 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 10:59:58 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <353707308.295851.1302790062753.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110414135710.GA727@redhat.com> <353707308.295851.1302790062753.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414145957.GA9899@redhat.com> * Denis Lila [2011-04-14 10:07]: > > NetxPanel inherits from AVP, so why is the cast needed? Does NetxPanel > > override the method? > > Yes, NetxPanel overrides the 3 methods that we need the casts for. > Since they're protected, but NetxPanel is in a different package, > the compiler gives an error. > Ah okay then, thats what I suspected too. > > > That said, I wouldn't mind changing the type of appletPanels > > > to Vector. Do you still think I should? > > > > > > > Actually, perhaps we should go one step up and just change it to > > NetxPanel? We only store those in the vector anyway. > > We could, but I would rather not because we only use that vector > for the "applet" field of the AppletPanel class. We don't need > a NetxPanel for that. Using a NetxPanel would add irrelevant details. > It is not irrelevant to strongly type a container. Strong typing will catch errors at compile time whereas weak typing will show them at runtime. Cheers, Deepak > Regards, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-14 09:45]: > > > > Instead of doing this, it would be easier to change the type of > > > > appletPanels to Vector , then the casting is > > > > not > > > > needed as AVP inherits from AP. > > > > > > The casting to AppletViewerPanel is not caused by appletPanels. It > > > is caused by the "panel" member. It used to be declared as an AVP, > > > then I changed it to a NetxPanel, which made the 3 new casts > > > necessary (but it eliminated many more casts than it added). > > > > > > > > > > > > > Cheers, > > Deepak > > > > > Thank you, > > > Denis. > > > > > > ----- Original Message ----- > > > > * Denis Lila [2011-04-13 15:10]: > > > > > > If a patch akin to > > > > > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > > > > > goes in, I will not be responsible for my actions. > > > > > > > > > > I definitely don't want that ;-). > > > > > > > > > > Attached is the second patch. It's mostly cleanup, and it > > > > > also uses "pav" in destroyApplet, instead of calling > > > > > get(id) again and again. > > > > > > > > > > Ok to push? > > > > > > > > > > > > > ... > > > > ... > > > > > > > > > > > > > > > > > > PluginDebug.debug("getCachedImageRef() getting img > > > > > from > > > > > URL = ", url); > > > > > @@ -910,8 +815,8 @@ > > > > > SocketPermission panelSp = > > > > > new > > > > > SocketPermission(panel.getCodeBase().getHost(), > > > > > "connect"); > > > > > synchronized(appletPanels) { > > > > > - for (Enumeration e = appletPanels.elements(); > > > > > e.hasMoreElements();) { > > > > > - AppletPanel p = (AppletPanel) e.nextElement(); > > > > > + for (Enumeration e = appletPanels.elements(); > > > > > e.hasMoreElements();) { > > > > > + AppletPanel p = e.nextElement(); > > > > > String param = p.getParameter("name"); > > > > > if (param != null) { > > > > > param = param.toLowerCase(); > > > > > @@ -1591,15 +1496,15 @@ > > > > > * at the same time. > > > > > */ > > > > > try { > > > > > - panel.joinAppletThread(); > > > > > - panel.release(); > > > > > + ((AppletViewerPanel)panel).joinAppletThread(); > > > > > + ((AppletViewerPanel)panel).release(); > > > > > } catch (InterruptedException e) { > > > > > return; // abort the reload > > > > > } > > > > > > > > > > AccessController.doPrivileged(new > > > > > PrivilegedAction() > > > > > { > > > > > public Void run() { > > > > > - panel.createAppletThread(); > > > > > + ((AppletViewerPanel)panel).createAppletThread(); > > > > > return null; > > > > > } > > > > > > > > > > > From dbhole at redhat.com Thu Apr 14 08:04:15 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 11:04:15 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <4DA70B10.4030801@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <4DA70B10.4030801@redhat.com> Message-ID: <20110414150415.GB9899@redhat.com> * Omair Majid [2011-04-14 10:56]: > On 04/14/2011 01:56 AM, Deepak Bhole wrote: > >* Deepak Bhole [2011-04-13 20:48]: > >>> Hi, > >>> > >>> Andrew mentioned in one of the previous threads that the current plugin > >>> code waits in an inefficient manner. It wakes up periodically to > >>> check for conditions, and goes back to sleep, and keeps doing that > >>> cyclically. > >>> > >>> The attached patch uses a new function that uses object.wait for > >>> the object of interest. > >>> > >Please see attached new patch. After leaving the office I realized that > >there is a potential race condition in the old patch with locking the > >object inside the wait function. Patch updated to do the locking > >outside (and function comment updated to clearly state that). > > > >Cheers, > >Deepak > > > > > >wait-fixes.patch > > > > > >diff -r 2ef65ff10619 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > >--- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 19:17:21 2011 -0400 > >+++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 01:54:04 2011 -0400 > >@@ -91,12 +91,10 @@ > > import java.security.PrivilegedAction; > > import java.security.PrivilegedActionException; > > import java.security.PrivilegedExceptionAction; > >-import java.util.ArrayList; > > import java.util.Enumeration; > > import java.util.HashMap; > > import java.util.Hashtable; > > import java.util.Iterator; > >-import java.util.List; > > import java.util.Map; > > import java.util.Vector; > > import java.util.concurrent.ConcurrentHashMap; > >@@ -142,14 +140,19 @@ > > initEventQueue(panel); > > > > // Wait for panel to come alive > >- int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > >- int wait = 0; > >- while (!panel.isAlive()&& wait< maxWait) { > >- try { > >- Thread.sleep(50); > >- wait += 50; > >- } catch (InterruptedException ie) { > >- // just wait > >+ // Wait implemented the long way so that > >+ // PluginAppletViewer.waitTillTimeout() needn't be exposed. > >+ long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > >+ > >+ synchronized(panel) { > >+ while (!panel.isAlive()&& maxTimeToSleep> 0) { > >+ long sleepStart = System.currentTimeMillis(); > >+ > >+ try { > >+ panel.wait(maxTimeToSleep); > >+ } catch (InterruptedException e) {} // Just loop back > >+ > >+ maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); > > Can you not use waitTillTimeout here? > Nope, it is in a different class. That is why I added a comment above it stating why it was done so. To use that, I would have to make PluginAppletViewer.waitTillTimeout() public and I would rather not expose that for use elsewhere in its current state. I am working on a refactor to address it correctly. > Also, perhaps we should be using System.nanoTime() instead of > System.currentTimeMillis(). > > Using System.currenTimeMillis() relies on the assumption that the > user's clock does not change. If a daylight savings change happens > to kick in, or the computer's clock is updated (say, based on NTP), > then the results of currentTimeMillis() can be quite disastrous > (especially if the clock moved backwards). > > System.nanoTime() uses clock_gettime(CLOCK_MONOTONIC) (where > supported) so it should be safe from any changes in the clock. > Ah, neat. I didn't know that. I will make the change. Thanks, Deepak From jvanek at redhat.com Thu Apr 14 08:02:21 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Thu, 14 Apr 2011 17:02:21 +0200 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414150415.GB9899@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <4DA70B10.4030801@redhat.com> <20110414150415.GB9899@redhat.com> Message-ID: <4DA70C7D.6080401@redhat.com> On 04/14/2011 05:04 PM, Deepak Bhole wrote: > * Omair Majid [2011-04-14 10:56]: >> On 04/14/2011 01:56 AM, Deepak Bhole wrote: >>> * Deepak Bhole [2011-04-13 20:48]: >>>>> Hi, >>>>> >>>>> Andrew mentioned in one of the previous threads that the current plugin >>>>> code waits in an inefficient manner. It wakes up periodically to >>>>> check for conditions, and goes back to sleep, and keeps doing that >>>>> cyclically. >>>>> >>>>> The attached patch uses a new function that uses object.wait for >>>>> the object of interest. >>>>> >>> Please see attached new patch. After leaving the office I realized that >>> there is a potential race condition in the old patch with locking the >>> object inside the wait function. Patch updated to do the locking >>> outside (and function comment updated to clearly state that). >>> >>> Cheers, >>> Deepak >>> >>> >>> wait-fixes.patch >>> >>> >>> diff -r 2ef65ff10619 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java >>> --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 19:17:21 2011 -0400 >>> +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 01:54:04 2011 -0400 >>> @@ -91,12 +91,10 @@ >>> import java.security.PrivilegedAction; >>> import java.security.PrivilegedActionException; >>> import java.security.PrivilegedExceptionAction; >>> -import java.util.ArrayList; >>> import java.util.Enumeration; >>> import java.util.HashMap; >>> import java.util.Hashtable; >>> import java.util.Iterator; >>> -import java.util.List; >>> import java.util.Map; >>> import java.util.Vector; >>> import java.util.concurrent.ConcurrentHashMap; >>> @@ -142,14 +140,19 @@ >>> initEventQueue(panel); >>> >>> // Wait for panel to come alive >>> - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive >>> - int wait = 0; >>> - while (!panel.isAlive()&& wait< maxWait) { >>> - try { >>> - Thread.sleep(50); >>> - wait += 50; >>> - } catch (InterruptedException ie) { >>> - // just wait >>> + // Wait implemented the long way so that >>> + // PluginAppletViewer.waitTillTimeout() needn't be exposed. >>> + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; >>> + >>> + synchronized(panel) { >>> + while (!panel.isAlive()&& maxTimeToSleep> 0) { >>> + long sleepStart = System.currentTimeMillis(); >>> + >>> + try { >>> + panel.wait(maxTimeToSleep); >>> + } catch (InterruptedException e) {} // Just loop back >>> + >>> + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); >> >> Can you not use waitTillTimeout here? >> > > Nope, it is in a different class. That is why I added a comment above it > stating why it was done so. To use that, I would have to make > PluginAppletViewer.waitTillTimeout() public and I would rather not > expose that for use elsewhere in its current state. I am working on a > refactor to address it correctly. > >> Also, perhaps we should be using System.nanoTime() instead of >> System.currentTimeMillis(). >> >> Using System.currenTimeMillis() relies on the assumption that the >> user's clock does not change. If a daylight savings change happens >> to kick in, or the computer's clock is updated (say, based on NTP), >> then the results of currentTimeMillis() can be quite disastrous >> (especially if the clock moved backwards). >> >> System.nanoTime() uses clock_gettime(CLOCK_MONOTONIC) (where >> supported) so it should be safe from any changes in the clock. >> > > Ah, neat. I didn't know that. I will make the change. > > Thanks, > Deepak > Don't forgot then that nanoTime can be negative. From dlila at redhat.com Thu Apr 14 08:43:52 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 11:43:52 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110414145957.GA9899@redhat.com> Message-ID: <2053431840.305447.1302795832535.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > It is not irrelevant to strongly type a container. What I meant by irrelevant is that NetxPanel is a subclass, so it adds to the implementation of AppletPanel. We don't need any of what it adds, because the only reason we have appletPanels is so we can implement getApplet(String) and getApplets(). These methods only need a container whose elements have an applet field, and Vector is enough for that. > Strong typing will catch errors at compile time whereas weak > typing will show them at runtime. The reason for that is because when a container is weakly typed we may put bad data in it and get ClassCastExceptions when we manually cast. In this case, however, we never do any casts because the type is exactly as strong as it needs to be, because all we need is the ".applet" member, and AppletPanel has it. Do you still think I should change it to NetxPanel? Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-14 10:07]: > > > NetxPanel inherits from AVP, so why is the cast needed? Does > > > NetxPanel > > > override the method? > > > > Yes, NetxPanel overrides the 3 methods that we need the casts for. > > Since they're protected, but NetxPanel is in a different package, > > the compiler gives an error. > > > > Ah okay then, thats what I suspected too. > > > > > That said, I wouldn't mind changing the type of appletPanels > > > > to Vector. Do you still think I should? > > > > > > > > > > Actually, perhaps we should go one step up and just change it to > > > NetxPanel? We only store those in the vector anyway. > > > > We could, but I would rather not because we only use that vector > > for the "applet" field of the AppletPanel class. We don't need > > a NetxPanel for that. Using a NetxPanel would add irrelevant > > details. > > > > > Cheers, > Deepak > > > Regards, > > Denis. > > > > ----- Original Message ----- > > > * Denis Lila [2011-04-14 09:45]: > > > > > Instead of doing this, it would be easier to change the type > > > > > of > > > > > appletPanels to Vector , then the casting > > > > > is > > > > > not > > > > > needed as AVP inherits from AP. > > > > > > > > The casting to AppletViewerPanel is not caused by appletPanels. > > > > It > > > > is caused by the "panel" member. It used to be declared as an > > > > AVP, > > > > then I changed it to a NetxPanel, which made the 3 new casts > > > > necessary (but it eliminated many more casts than it added). > > > > > > > > > > > > > > > > > > > > Cheers, > > > Deepak > > > > > > > Thank you, > > > > Denis. > > > > > > > > ----- Original Message ----- > > > > > * Denis Lila [2011-04-13 15:10]: > > > > > > > If a patch akin to > > > > > > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > > > > > > goes in, I will not be responsible for my actions. > > > > > > > > > > > > I definitely don't want that ;-). > > > > > > > > > > > > Attached is the second patch. It's mostly cleanup, and it > > > > > > also uses "pav" in destroyApplet, instead of calling > > > > > > get(id) again and again. > > > > > > > > > > > > Ok to push? > > > > > > > > > > > > > > > > ... > > > > > ... > > > > > > > > > > > > > > > > > > > > > > PluginDebug.debug("getCachedImageRef() getting > > > > > > img > > > > > > from > > > > > > URL = ", url); > > > > > > @@ -910,8 +815,8 @@ > > > > > > SocketPermission panelSp = > > > > > > new > > > > > > SocketPermission(panel.getCodeBase().getHost(), > > > > > > "connect"); > > > > > > synchronized(appletPanels) { > > > > > > - for (Enumeration e = appletPanels.elements(); > > > > > > e.hasMoreElements();) { > > > > > > - AppletPanel p = (AppletPanel) e.nextElement(); > > > > > > + for (Enumeration e = appletPanels.elements(); > > > > > > e.hasMoreElements();) { > > > > > > + AppletPanel p = e.nextElement(); > > > > > > String param = p.getParameter("name"); > > > > > > if (param != null) { > > > > > > param = param.toLowerCase(); > > > > > > @@ -1591,15 +1496,15 @@ > > > > > > * at the same time. > > > > > > */ > > > > > > try { > > > > > > - panel.joinAppletThread(); > > > > > > - panel.release(); > > > > > > + ((AppletViewerPanel)panel).joinAppletThread(); > > > > > > + ((AppletViewerPanel)panel).release(); > > > > > > } catch (InterruptedException e) { > > > > > > return; // abort the reload > > > > > > } > > > > > > > > > > > > AccessController.doPrivileged(new > > > > > > PrivilegedAction() > > > > > > { > > > > > > public Void run() { > > > > > > - panel.createAppletThread(); > > > > > > + ((AppletViewerPanel)panel).createAppletThread(); > > > > > > return null; > > > > > > } > > > > > > > > > > > > > > From dbhole at redhat.com Thu Apr 14 08:51:02 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 11:51:02 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <2053431840.305447.1302795832535.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110414145957.GA9899@redhat.com> <2053431840.305447.1302795832535.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414155102.GD9899@redhat.com> * Denis Lila [2011-04-14 11:43]: > > It is not irrelevant to strongly type a container. > > What I meant by irrelevant is that NetxPanel is a subclass, so it > adds to the implementation of AppletPanel. We don't need any > of what it adds, because the only reason we have appletPanels > is so we can implement getApplet(String) and getApplets(). > These methods only need a container whose elements have an > applet field, and Vector is enough for that. > > > Strong typing will catch errors at compile time whereas weak > > typing will show them at runtime. > > The reason for that is because when a container is weakly typed > we may put bad data in it and get ClassCastExceptions when we > manually cast. In this case, however, we never do any casts > because the type is exactly as strong as it needs to be, > because all we need is the ".applet" member, and AppletPanel > has it. > I know we are only using at as AP right now. However that may change in the future. And rather than relying on someone making the right change in the future (as opposed to just casting it to NP), it is best to do the right thing as we spot it a potential problem. > Do you still think I should change it to NetxPanel? > Yes please. Cheers, Deepak > Regards, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-14 10:07]: > > > > NetxPanel inherits from AVP, so why is the cast needed? Does > > > > NetxPanel > > > > override the method? > > > > > > Yes, NetxPanel overrides the 3 methods that we need the casts for. > > > Since they're protected, but NetxPanel is in a different package, > > > the compiler gives an error. > > > > > > > Ah okay then, thats what I suspected too. > > > > > > > That said, I wouldn't mind changing the type of appletPanels > > > > > to Vector. Do you still think I should? > > > > > > > > > > > > > Actually, perhaps we should go one step up and just change it to > > > > NetxPanel? We only store those in the vector anyway. > > > > > > We could, but I would rather not because we only use that vector > > > for the "applet" field of the AppletPanel class. We don't need > > > a NetxPanel for that. Using a NetxPanel would add irrelevant > > > details. > > > > > > > > > Cheers, > > Deepak > > > > > Regards, > > > Denis. > > > > > > ----- Original Message ----- > > > > * Denis Lila [2011-04-14 09:45]: > > > > > > Instead of doing this, it would be easier to change the type > > > > > > of > > > > > > appletPanels to Vector , then the casting > > > > > > is > > > > > > not > > > > > > needed as AVP inherits from AP. > > > > > > > > > > The casting to AppletViewerPanel is not caused by appletPanels. > > > > > It > > > > > is caused by the "panel" member. It used to be declared as an > > > > > AVP, > > > > > then I changed it to a NetxPanel, which made the 3 new casts > > > > > necessary (but it eliminated many more casts than it added). > > > > > > > > > > > > > > > > > > > > > > > > > > > Cheers, > > > > Deepak > > > > > > > > > Thank you, > > > > > Denis. > > > > > > > > > > ----- Original Message ----- > > > > > > * Denis Lila [2011-04-13 15:10]: > > > > > > > > If a patch akin to > > > > > > > > http://hg.openjdk.java.net/jdk6/jdk6/langtools/rev/5c2858bccb3f > > > > > > > > goes in, I will not be responsible for my actions. > > > > > > > > > > > > > > I definitely don't want that ;-). > > > > > > > > > > > > > > Attached is the second patch. It's mostly cleanup, and it > > > > > > > also uses "pav" in destroyApplet, instead of calling > > > > > > > get(id) again and again. > > > > > > > > > > > > > > Ok to push? > > > > > > > > > > > > > > > > > > > ... > > > > > > ... > > > > > > > > > > > > > > > > > > > > > > > > > > PluginDebug.debug("getCachedImageRef() getting > > > > > > > img > > > > > > > from > > > > > > > URL = ", url); > > > > > > > @@ -910,8 +815,8 @@ > > > > > > > SocketPermission panelSp = > > > > > > > new > > > > > > > SocketPermission(panel.getCodeBase().getHost(), > > > > > > > "connect"); > > > > > > > synchronized(appletPanels) { > > > > > > > - for (Enumeration e = appletPanels.elements(); > > > > > > > e.hasMoreElements();) { > > > > > > > - AppletPanel p = (AppletPanel) e.nextElement(); > > > > > > > + for (Enumeration e = appletPanels.elements(); > > > > > > > e.hasMoreElements();) { > > > > > > > + AppletPanel p = e.nextElement(); > > > > > > > String param = p.getParameter("name"); > > > > > > > if (param != null) { > > > > > > > param = param.toLowerCase(); > > > > > > > @@ -1591,15 +1496,15 @@ > > > > > > > * at the same time. > > > > > > > */ > > > > > > > try { > > > > > > > - panel.joinAppletThread(); > > > > > > > - panel.release(); > > > > > > > + ((AppletViewerPanel)panel).joinAppletThread(); > > > > > > > + ((AppletViewerPanel)panel).release(); > > > > > > > } catch (InterruptedException e) { > > > > > > > return; // abort the reload > > > > > > > } > > > > > > > > > > > > > > AccessController.doPrivileged(new > > > > > > > PrivilegedAction() > > > > > > > { > > > > > > > public Void run() { > > > > > > > - panel.createAppletThread(); > > > > > > > + ((AppletViewerPanel)panel).createAppletThread(); > > > > > > > return null; > > > > > > > } > > > > > > > > > > > > > > > > > From dlila at redhat.com Thu Apr 14 09:01:52 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 12:01:52 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110414155102.GD9899@redhat.com> Message-ID: <627407559.305696.1302796911930.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > > Do you still think I should change it to NetxPanel? > Yes please. Ok. I attached the patch with the updated ChangeLog. Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-14 11:43]: > > > It is not irrelevant to strongly type a container. > > > > What I meant by irrelevant is that NetxPanel is a subclass, so it > > adds to the implementation of AppletPanel. We don't need any ... From dlila at redhat.com Thu Apr 14 09:02:48 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 12:02:48 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <627407559.305696.1302796911930.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1114543399.305714.1302796968214.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Ok. > I attached the patch with the updated ChangeLog. *sigh*, _now_ I attached the patch. ----- Original Message ----- > > > Do you still think I should change it to NetxPanel? > > Yes please. > > > Regards, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-14 11:43]: > > > > It is not irrelevant to strongly type a container. > > > > > > What I meant by irrelevant is that NetxPanel is a subclass, so it > > > adds to the implementation of AppletPanel. We don't need any > ... -------------- next part -------------- A non-text attachment was scrubbed... Name: RefactorPAV.patch Type: text/x-patch Size: 19891 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110414/f8adee7e/RefactorPAV.patch From dbhole at redhat.com Thu Apr 14 09:13:00 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 12:13:00 -0400 Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <1114543399.305714.1302796968214.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <627407559.305696.1302796911930.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <1114543399.305714.1302796968214.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414161259.GE9899@redhat.com> * Denis Lila [2011-04-14 12:02]: > > Ok. > > I attached the patch with the updated ChangeLog. > > *sigh*, _now_ I attached the patch. > The ChangeLog in the patch has a line over 80 chars. Assuming the only change between this and the last patch I reviewed is the change of the vector type, OK for commit after fixing the ChangeLog. Thanks, Deepak > ----- Original Message ----- > > > > Do you still think I should change it to NetxPanel? > > > Yes please. > > > > > > > Regards, > > Denis. > > > > ----- Original Message ----- > > > * Denis Lila [2011-04-14 11:43]: > > > > > It is not irrelevant to strongly type a container. > > > > > > > > What I meant by irrelevant is that NetxPanel is a subclass, so it > > > > adds to the implementation of AppletPanel. We don't need any > > ... > diff -r c84f2e5b039f ChangeLog > --- a/ChangeLog Wed Apr 13 12:18:38 2011 -0400 > +++ b/ChangeLog Thu Apr 14 12:05:10 2011 -0400 > @@ -1,3 +1,21 @@ > +2011-04-14 Denis Lila > + > + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > + Remove unused imports, added various SuppressWarnings annotations. > + (createPanel): Return NetxPanel from doPriviledged. Remove dead code. > + (PluginParseRequest): Remove - unused. > + (defaultSaveFile, label, statusMsgStream, requests, handle): Remove - unused. > + (panel): Make NetxPanel. > + (identifier, appletPanels): Privatize. > + (appletPanels): Change type to NetxPanel. > + (applets, status): Use ConcurrentHashMaps. > + (framePanel, PluginAppletViewer): Remove unused PrintStream argument. > + (forceredraw): Remove - unused. > + (getApplets): Use generics. > + (appletClose): Fix style to match our convention. > + (destroyApplet): Use pav instead of calling get many times. > + (splitSeparator): Remove. Replace uses by String.split(). > + > 2011-04-12 Denis Lila > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > diff -r c84f2e5b039f plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 12:18:38 2011 -0400 > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 12:05:10 2011 -0400 > @@ -70,23 +70,19 @@ > import java.awt.Graphics; > import java.awt.Image; > import java.awt.Insets; > -import java.awt.Label; > import java.awt.Toolkit; > import java.awt.event.WindowAdapter; > import java.awt.event.WindowEvent; > import java.awt.event.WindowListener; > import java.awt.print.PageFormat; > import java.awt.print.Printable; > -import java.io.BufferedReader; > import java.io.IOException; > import java.io.InputStream; > -import java.io.InputStreamReader; > import java.io.PrintStream; > import java.io.Reader; > import java.io.StringReader; > import java.io.UnsupportedEncodingException; > import java.lang.reflect.InvocationTargetException; > -import java.net.MalformedURLException; > import java.net.SocketPermission; > import java.net.URI; > import java.net.URL; > @@ -128,49 +124,27 @@ > long handle, int x, int y, > final URL doc, > final Hashtable atts) { > - AppletViewerPanel panel = AccessController.doPrivileged(new PrivilegedAction() { > - public AppletViewerPanel run() { > - try { > - AppletViewerPanel panel = new NetxPanel(doc, atts, false); > - AppletViewerPanel.debug("Using NetX panel"); > - PluginDebug.debug(atts.toString()); > - return panel; > - } catch (Exception ex) { > - AppletViewerPanel.debug("Unable to start NetX applet - defaulting to Sun applet", ex); > - return new AppletViewerPanel(doc, atts); > - } > + NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { > + public NetxPanel run() { > + NetxPanel panel = new NetxPanel(doc, atts, false); > + NetxPanel.debug("Using NetX panel"); > + PluginDebug.debug(atts.toString()); > + return panel; > } > }); > > // create the frame. > - PluginAppletViewer.framePanel(identifier, System.out, handle, panel); > + PluginAppletViewer.framePanel(identifier, handle, panel); > > panel.init(); > > // Start the applet > initEventQueue(panel); > > - // Applet initialized. Find out it's classloader and add it to the list > - String portComponent = doc.getPort() != -1 ? ":" + doc.getPort() : ""; > - String codeBase = doc.getProtocol() + "://" + doc.getHost() + portComponent; > - > - if (atts.get("codebase") != null) { > - try { > - URL appletSrcURL = new URL(codeBase + atts.get("codebase")); > - codeBase = appletSrcURL.getProtocol() + "://" + appletSrcURL.getHost(); > - } catch (MalformedURLException mfue) { > - // do nothing > - } > - } > - > - // Wait for the panel to initialize > - // (happens in a separate thread) > - Applet a; > - > // Wait for panel to come alive > int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > int wait = 0; > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait < maxWait)) { > + while (!panel.isAlive() && wait < maxWait) { > try { > Thread.sleep(50); > wait += 50; > @@ -181,12 +155,12 @@ > > // Wait for the panel to initialize > // (happens in a separate thread) > - PluginAppletViewer.waitForAppletInit((NetxPanel) panel); > + PluginAppletViewer.waitForAppletInit(panel); > > - a = panel.getApplet(); > + Applet a = panel.getApplet(); > > // Still null? > - if (panel.getApplet() == null) { > + if (a == null) { > streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > return null; > } > @@ -194,8 +168,8 @@ > PluginDebug.debug("Applet ", a.getClass(), " initialized"); > streamhandler.write("instance " + identifier + " reference 0 initialized"); > > - AppletSecurityContextManager.getSecurityContext(0).associateSrc(((NetxPanel) panel).getAppletClassLoader(), doc); > - AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, ((NetxPanel) panel).getAppletClassLoader()); > + AppletSecurityContextManager.getSecurityContext(0).associateSrc(panel.getAppletClassLoader(), doc); > + AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, panel.getAppletClassLoader()); > > return panel; > } > @@ -231,7 +205,7 @@ > > // The list of events that will be executed is provided as a > // ","-separated list. No error-checking will be done on the list. > - String[] events = splitSeparator(",", eventList); > + String[] events = eventList.split(","); > > for (int i = 0; i < events.length; i++) { > PluginDebug.debug("Adding event to queue: ", events[i]); > @@ -260,52 +234,14 @@ > ; > } > } > - > - /** > - * Split a string based on the presence of a specified separator. Returns > - * an array of arbitrary length. The end of each element in the array is > - * indicated by the separator of the end of the string. If there is a > - * separator immediately before the end of the string, the final element > - * will be empty. None of the strings will contain the separator. Useful > - * when separating strings such as "foo/bar/bas" using separator "/". > - * > - * @param sep The separator. > - * @param s The string to split. > - * @return An array of strings. Each string in the array is determined > - * by the location of the provided sep in the original string, > - * s. Whitespace not stripped. > - */ > - private String[] splitSeparator(String sep, String s) { > - List l = new ArrayList(); > - int tokenStart = 0; > - int tokenEnd = 0; > - > - while ((tokenEnd = s.indexOf(sep, tokenStart)) != -1) { > - l.add(s.substring(tokenStart, tokenEnd)); > - tokenStart = tokenEnd + 1; > - } > - // Add the final element. > - l.add(s.substring(tokenStart)); > - > - return l.toArray(new String[l.size()]); > - } > -} > - > -class PluginParseRequest { > - long handle; > - String tag; > - String documentbase; > } > > /* > */ > // FIXME: declare JSProxy implementation > + at SuppressWarnings("serial") > public class PluginAppletViewer extends XEmbeddedFrame > implements AppletContext, Printable { > - /** > - * Some constants... > - */ > - private static String defaultSaveFile = "Applet.ser"; > > /** > * Enumerates the current status of an applet > @@ -323,23 +259,9 @@ > /** > * The panel in which the applet is being displayed. > */ > - AppletViewerPanel panel; > + private NetxPanel panel; > > - /** > - * The status line. > - */ > - Label label; > - > - /** > - * output status messages to this stream > - */ > - > - PrintStream statusMsgStream; > - > - int identifier; > - > - private static HashMap requests = > - new HashMap(); > + private int identifier; > > // Instance identifier -> PluginAppletViewer object. > private static ConcurrentMap applets = > @@ -352,7 +274,6 @@ > private static ConcurrentMap status = > new ConcurrentHashMap(); > > - private long handle = 0; > private WindowListener windowEventListener = null; > private AppletEventListener appletEventListener = null; > > @@ -370,15 +291,14 @@ > public PluginAppletViewer() { > } > > - public static void framePanel(int identifier, PrintStream statusMsgStream, > - long handle, AppletViewerPanel panel) { > + public static void framePanel(int identifier, long handle, NetxPanel panel) { > > PluginDebug.debug("Framing ", panel); > > // SecurityManager MUST be set, and only privileged code may call reFrame() > System.getSecurityManager().checkPermission(new AllPermission()); > > - PluginAppletViewer appletFrame = new PluginAppletViewer(handle, identifier, statusMsgStream, panel); > + PluginAppletViewer appletFrame = new PluginAppletViewer(handle, identifier, panel); > > appletFrame.add("Center", panel); > appletFrame.pack(); > @@ -395,11 +315,9 @@ > * Create new plugin appletviewer frame > */ > private PluginAppletViewer(long handle, final int identifier, > - PrintStream statusMsgStream, > - AppletViewerPanel appletPanel) { > + NetxPanel appletPanel) { > > super(handle, true); > - this.statusMsgStream = statusMsgStream; > this.identifier = identifier; > this.panel = appletPanel; > > @@ -547,13 +465,11 @@ > if (wait >= maxWait) > throw new Exception("Applet initialization timeout"); > > - PluginAppletViewer oldFrame = applets.get(identifier); > - > // We should not try to destroy an applet during > // initialization. It may cause an inconsistent state, > // which would bad if it's a trusted applet that > // read/writes to files > - waitForAppletInit((NetxPanel) applets.get(identifier).panel); > + waitForAppletInit(applets.get(identifier).panel); > > // Should we proceed with reframing? > if (updateStatus(identifier, PAV_INIT_STATUS.REFRAME_COMPLETE).equals(PAV_INIT_STATUS.INACTIVE)) { > @@ -660,25 +576,25 @@ > PluginDebug.debug("Attempting to destroy frame ", identifier); > > // Try to dispose the panel right away > - PluginAppletViewer pav = applets.get(identifier); > - if (pav != null) > + final PluginAppletViewer pav = applets.get(identifier); > + if (pav != null) { > pav.dispose(); > > - // If panel is already disposed, return > - if (applets.get(identifier).panel.applet == null) { > - PluginDebug.debug(identifier, " panel inactive. Returning."); > - return; > + // If panel is already disposed, return > + if (pav.panel.applet == null) { > + PluginDebug.debug(identifier, " panel inactive. Returning."); > + return; > + } > + > + PluginDebug.debug("Attempting to destroy panel ", identifier); > + > + SwingUtilities.invokeLater(new Runnable() { > + public void run() { > + pav.appletClose(); > + } > + }); > } > > - PluginDebug.debug("Attempting to destroy panel ", identifier); > - > - final int fIdentifier = identifier; > - SwingUtilities.invokeLater(new Runnable() { > - public void run() { > - applets.get(fIdentifier).appletClose(); > - } > - }); > - > PluginDebug.debug(identifier, " destroyed"); > } > > @@ -729,8 +645,7 @@ > final int height = Integer.parseInt(dimMsg[3]); > final int width = Integer.parseInt(dimMsg[1]); > > - if (panel instanceof NetxPanel) > - ((NetxPanel) panel).updateSizeInAtts(height, width); > + panel.updateSizeInAtts(height, width); > > try { > SwingUtilities.invokeAndWait(new Runnable() { > @@ -775,7 +690,7 @@ > // Wait for panel to come alive > int maxWait = APPLET_TIMEOUT; // wait for panel to come alive > int wait = 0; > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait < maxWait)) { > + while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { > try { > Thread.sleep(50); > wait += 50; > @@ -786,13 +701,13 @@ > > // Wait for the panel to initialize > // (happens in a separate thread) > - waitForAppletInit((NetxPanel) panel); > + waitForAppletInit(panel); > > - PluginDebug.debug(panel, " -- ", panel.getApplet(), " -- ", ((NetxPanel) panel).isAlive()); > + PluginDebug.debug(panel, " -- ", panel.getApplet(), " -- ", panel.isAlive()); > > // Still null? > if (panel.getApplet() == null) { > - this.streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > + streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); > return; > } > > @@ -807,11 +722,6 @@ > } > } > > - // FIXME: Kind of hackish way to ensure synchronized re-drawing > - private synchronized void forceredraw() { > - doLayout(); > - } > - > /* > * Methods for java.applet.AppletContext > */ > @@ -861,19 +771,14 @@ > PluginDebug.debug("getCachedImageRef() got URL = ", url); > PluginDebug.debug("getCachedImageRef() plugin codebase = ", codeBase); > > - // try to fetch it locally > - if (panel instanceof NetxPanel) { > + String resourceName = originalURL.substring(codeBase.length()); > + JNLPClassLoader loader = (JNLPClassLoader) panel.getAppletClassLoader(); > > - URL localURL = null; > + URL localURL = null; > + if (loader.resourceAvailableLocally(resourceName)) > + url = loader.getResource(resourceName); > > - String resourceName = originalURL.substring(codeBase.length()); > - JNLPClassLoader loader = (JNLPClassLoader) ((NetxPanel) panel).getAppletClassLoader(); > - > - if (loader.resourceAvailableLocally(resourceName)) > - localURL = loader.getResource(resourceName); > - > - url = localURL != null ? localURL : url; > - } > + url = localURL != null ? localURL : url; > } > > PluginDebug.debug("getCachedImageRef() getting img from URL = ", url); > @@ -900,7 +805,7 @@ > imageRefs.clear(); > } > > - private static Vector appletPanels = new Vector(); > + private static Vector appletPanels = new Vector(); > > /** > * Get an applet by name. > @@ -910,8 +815,8 @@ > SocketPermission panelSp = > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > synchronized(appletPanels) { > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > - AppletPanel p = (AppletPanel) e.nextElement(); > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > + AppletPanel p = e.nextElement(); > String param = p.getParameter("name"); > if (param != null) { > param = param.toLowerCase(); > @@ -941,7 +846,7 @@ > new SocketPermission(panel.getCodeBase().getHost(), "connect"); > > synchronized(appletPanels) { > - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { > AppletPanel p = e.nextElement(); > if (p.getDocumentBase().equals(panel.getDocumentBase())) { > > @@ -1591,15 +1496,15 @@ > * at the same time. > */ > try { > - panel.joinAppletThread(); > - panel.release(); > + ((AppletViewerPanel)panel).joinAppletThread(); > + ((AppletViewerPanel)panel).release(); > } catch (InterruptedException e) { > return; // abort the reload > } > > AccessController.doPrivileged(new PrivilegedAction() { > public Void run() { > - panel.createAppletThread(); > + ((AppletViewerPanel)panel).createAppletThread(); > return null; > } > }); > @@ -1652,34 +1557,32 @@ > // > final AppletPanel p = panel; > > - new Thread(new Runnable() > - { > - public void run() > - { > - ClassLoader cl = p.applet.getClass().getClassLoader(); > - > - // Since we want to deal with JNLPClassLoader, extract it if this > - // is a codebase loader > - if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > - cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); > + new Thread(new Runnable() { > + @SuppressWarnings("deprecation") > + public void run() { > + ClassLoader cl = p.applet.getClass().getClassLoader(); > > - ThreadGroup tg = ((JNLPClassLoader) cl).getApplication().getThreadGroup(); > + // Since we want to deal with JNLPClassLoader, extract it if this > + // is a codebase loader > + if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > + cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); > > - appletShutdown(p); > - appletPanels.removeElement(p); > - dispose(); > + ThreadGroup tg = ((JNLPClassLoader) cl).getApplication().getThreadGroup(); > > - if (tg.activeCount() > 0) > - tg.stop(); > + appletShutdown(p); > + appletPanels.removeElement(p); > + dispose(); > > - if (countApplets() == 0) { > - appletSystemExit(); > - } > + if (tg.activeCount() > 0) > + tg.stop(); > > - updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); > - } > - }).start(); > + if (countApplets() == 0) { > + appletSystemExit(); > + } > > + updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); > + } > + }).start(); > } > > /** > @@ -1868,6 +1771,7 @@ > }); > } > > + @SuppressWarnings("unused") > public static void parse(int identifier, long handle, String width, > String height, Reader in, URL url, > PrintStream statusMsgStream, From dlila at icedtea.classpath.org Thu Apr 14 09:21:09 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Thu, 14 Apr 2011 16:21:09 +0000 Subject: /hg/icedtea-web: Refactor PluginAppletViewer.java. Message-ID: changeset 72de6393baca in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=72de6393baca author: Denis Lila date: Thu Apr 14 12:24:46 2011 -0400 Refactor PluginAppletViewer.java. diffstat: ChangeLog | 18 + plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 246 ++++---------- 2 files changed, 93 insertions(+), 171 deletions(-) diffs (truncated from 506 to 500 lines): diff -r 1e661bc821f8 -r 72de6393baca ChangeLog --- a/ChangeLog Wed Apr 13 17:23:49 2011 -0400 +++ b/ChangeLog Thu Apr 14 12:24:46 2011 -0400 @@ -1,3 +1,21 @@ +2011-04-14 Denis Lila + + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java + Remove unused imports, added various SuppressWarnings annotations. + (createPanel): Return NetxPanel from doPriviledged. Remove dead code. + (PluginParseRequest): Remove - unused. + (defaultSaveFile, label, statusMsgStream, requests, handle): Remove unused. + (panel): Make NetxPanel. + (identifier, appletPanels): Privatize. + (appletPanels): Change type to NetxPanel. + (applets, status): Use ConcurrentHashMaps. + (framePanel, PluginAppletViewer): Remove unused PrintStream argument. + (forceredraw): Remove - unused. + (getApplets): Use generics. + (appletClose): Fix style to match our convention. + (destroyApplet): Use pav instead of calling get many times. + (splitSeparator): Remove. Replace uses by String.split(). + 2011-04-13 Andrew Su * netx/net/sourceforge/jnlp/cache/CacheDirectory.java: diff -r 1e661bc821f8 -r 72de6393baca plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 17:23:49 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 12:24:46 2011 -0400 @@ -70,23 +70,19 @@ import java.awt.Graphics; import java.awt.Image; import java.awt.Insets; -import java.awt.Label; import java.awt.Toolkit; import java.awt.event.WindowAdapter; import java.awt.event.WindowEvent; import java.awt.event.WindowListener; import java.awt.print.PageFormat; import java.awt.print.Printable; -import java.io.BufferedReader; import java.io.IOException; import java.io.InputStream; -import java.io.InputStreamReader; import java.io.PrintStream; import java.io.Reader; import java.io.StringReader; import java.io.UnsupportedEncodingException; import java.lang.reflect.InvocationTargetException; -import java.net.MalformedURLException; import java.net.SocketPermission; import java.net.URI; import java.net.URL; @@ -128,49 +124,27 @@ long handle, int x, int y, final URL doc, final Hashtable atts) { - AppletViewerPanel panel = AccessController.doPrivileged(new PrivilegedAction() { - public AppletViewerPanel run() { - try { - AppletViewerPanel panel = new NetxPanel(doc, atts, false); - AppletViewerPanel.debug("Using NetX panel"); - PluginDebug.debug(atts.toString()); - return panel; - } catch (Exception ex) { - AppletViewerPanel.debug("Unable to start NetX applet - defaulting to Sun applet", ex); - return new AppletViewerPanel(doc, atts); - } + NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { + public NetxPanel run() { + NetxPanel panel = new NetxPanel(doc, atts, false); + NetxPanel.debug("Using NetX panel"); + PluginDebug.debug(atts.toString()); + return panel; } }); // create the frame. - PluginAppletViewer.framePanel(identifier, System.out, handle, panel); + PluginAppletViewer.framePanel(identifier, handle, panel); panel.init(); // Start the applet initEventQueue(panel); - // Applet initialized. Find out it's classloader and add it to the list - String portComponent = doc.getPort() != -1 ? ":" + doc.getPort() : ""; - String codeBase = doc.getProtocol() + "://" + doc.getHost() + portComponent; - - if (atts.get("codebase") != null) { - try { - URL appletSrcURL = new URL(codeBase + atts.get("codebase")); - codeBase = appletSrcURL.getProtocol() + "://" + appletSrcURL.getHost(); - } catch (MalformedURLException mfue) { - // do nothing - } - } - - // Wait for the panel to initialize - // (happens in a separate thread) - Applet a; - // Wait for panel to come alive int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive int wait = 0; - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait < maxWait)) { + while (!panel.isAlive() && wait < maxWait) { try { Thread.sleep(50); wait += 50; @@ -181,12 +155,12 @@ // Wait for the panel to initialize // (happens in a separate thread) - PluginAppletViewer.waitForAppletInit((NetxPanel) panel); + PluginAppletViewer.waitForAppletInit(panel); - a = panel.getApplet(); + Applet a = panel.getApplet(); // Still null? - if (panel.getApplet() == null) { + if (a == null) { streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); return null; } @@ -194,8 +168,8 @@ PluginDebug.debug("Applet ", a.getClass(), " initialized"); streamhandler.write("instance " + identifier + " reference 0 initialized"); - AppletSecurityContextManager.getSecurityContext(0).associateSrc(((NetxPanel) panel).getAppletClassLoader(), doc); - AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, ((NetxPanel) panel).getAppletClassLoader()); + AppletSecurityContextManager.getSecurityContext(0).associateSrc(panel.getAppletClassLoader(), doc); + AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, panel.getAppletClassLoader()); return panel; } @@ -231,7 +205,7 @@ // The list of events that will be executed is provided as a // ","-separated list. No error-checking will be done on the list. - String[] events = splitSeparator(",", eventList); + String[] events = eventList.split(","); for (int i = 0; i < events.length; i++) { PluginDebug.debug("Adding event to queue: ", events[i]); @@ -260,52 +234,14 @@ ; } } - - /** - * Split a string based on the presence of a specified separator. Returns - * an array of arbitrary length. The end of each element in the array is - * indicated by the separator of the end of the string. If there is a - * separator immediately before the end of the string, the final element - * will be empty. None of the strings will contain the separator. Useful - * when separating strings such as "foo/bar/bas" using separator "/". - * - * @param sep The separator. - * @param s The string to split. - * @return An array of strings. Each string in the array is determined - * by the location of the provided sep in the original string, - * s. Whitespace not stripped. - */ - private String[] splitSeparator(String sep, String s) { - List l = new ArrayList(); - int tokenStart = 0; - int tokenEnd = 0; - - while ((tokenEnd = s.indexOf(sep, tokenStart)) != -1) { - l.add(s.substring(tokenStart, tokenEnd)); - tokenStart = tokenEnd + 1; - } - // Add the final element. - l.add(s.substring(tokenStart)); - - return l.toArray(new String[l.size()]); - } -} - -class PluginParseRequest { - long handle; - String tag; - String documentbase; } /* */ // FIXME: declare JSProxy implementation + at SuppressWarnings("serial") public class PluginAppletViewer extends XEmbeddedFrame implements AppletContext, Printable { - /** - * Some constants... - */ - private static String defaultSaveFile = "Applet.ser"; /** * Enumerates the current status of an applet @@ -323,23 +259,9 @@ /** * The panel in which the applet is being displayed. */ - AppletViewerPanel panel; + private NetxPanel panel; - /** - * The status line. - */ - Label label; - - /** - * output status messages to this stream - */ - - PrintStream statusMsgStream; - - int identifier; - - private static HashMap requests = - new HashMap(); + private int identifier; // Instance identifier -> PluginAppletViewer object. private static ConcurrentMap applets = @@ -352,7 +274,6 @@ private static ConcurrentMap status = new ConcurrentHashMap(); - private long handle = 0; private WindowListener windowEventListener = null; private AppletEventListener appletEventListener = null; @@ -370,15 +291,14 @@ public PluginAppletViewer() { } - public static void framePanel(int identifier, PrintStream statusMsgStream, - long handle, AppletViewerPanel panel) { + public static void framePanel(int identifier, long handle, NetxPanel panel) { PluginDebug.debug("Framing ", panel); // SecurityManager MUST be set, and only privileged code may call reFrame() System.getSecurityManager().checkPermission(new AllPermission()); - PluginAppletViewer appletFrame = new PluginAppletViewer(handle, identifier, statusMsgStream, panel); + PluginAppletViewer appletFrame = new PluginAppletViewer(handle, identifier, panel); appletFrame.add("Center", panel); appletFrame.pack(); @@ -395,11 +315,9 @@ * Create new plugin appletviewer frame */ private PluginAppletViewer(long handle, final int identifier, - PrintStream statusMsgStream, - AppletViewerPanel appletPanel) { + NetxPanel appletPanel) { super(handle, true); - this.statusMsgStream = statusMsgStream; this.identifier = identifier; this.panel = appletPanel; @@ -547,13 +465,11 @@ if (wait >= maxWait) throw new Exception("Applet initialization timeout"); - PluginAppletViewer oldFrame = applets.get(identifier); - // We should not try to destroy an applet during // initialization. It may cause an inconsistent state, // which would bad if it's a trusted applet that // read/writes to files - waitForAppletInit((NetxPanel) applets.get(identifier).panel); + waitForAppletInit(applets.get(identifier).panel); // Should we proceed with reframing? if (updateStatus(identifier, PAV_INIT_STATUS.REFRAME_COMPLETE).equals(PAV_INIT_STATUS.INACTIVE)) { @@ -660,25 +576,25 @@ PluginDebug.debug("Attempting to destroy frame ", identifier); // Try to dispose the panel right away - PluginAppletViewer pav = applets.get(identifier); - if (pav != null) + final PluginAppletViewer pav = applets.get(identifier); + if (pav != null) { pav.dispose(); - // If panel is already disposed, return - if (applets.get(identifier).panel.applet == null) { - PluginDebug.debug(identifier, " panel inactive. Returning."); - return; + // If panel is already disposed, return + if (pav.panel.applet == null) { + PluginDebug.debug(identifier, " panel inactive. Returning."); + return; + } + + PluginDebug.debug("Attempting to destroy panel ", identifier); + + SwingUtilities.invokeLater(new Runnable() { + public void run() { + pav.appletClose(); + } + }); } - PluginDebug.debug("Attempting to destroy panel ", identifier); - - final int fIdentifier = identifier; - SwingUtilities.invokeLater(new Runnable() { - public void run() { - applets.get(fIdentifier).appletClose(); - } - }); - PluginDebug.debug(identifier, " destroyed"); } @@ -729,8 +645,7 @@ final int height = Integer.parseInt(dimMsg[3]); final int width = Integer.parseInt(dimMsg[1]); - if (panel instanceof NetxPanel) - ((NetxPanel) panel).updateSizeInAtts(height, width); + panel.updateSizeInAtts(height, width); try { SwingUtilities.invokeAndWait(new Runnable() { @@ -775,7 +690,7 @@ // Wait for panel to come alive int maxWait = APPLET_TIMEOUT; // wait for panel to come alive int wait = 0; - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait < maxWait)) { + while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { try { Thread.sleep(50); wait += 50; @@ -786,13 +701,13 @@ // Wait for the panel to initialize // (happens in a separate thread) - waitForAppletInit((NetxPanel) panel); + waitForAppletInit(panel); - PluginDebug.debug(panel, " -- ", panel.getApplet(), " -- ", ((NetxPanel) panel).isAlive()); + PluginDebug.debug(panel, " -- ", panel.getApplet(), " -- ", panel.isAlive()); // Still null? if (panel.getApplet() == null) { - this.streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); + streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); return; } @@ -807,11 +722,6 @@ } } - // FIXME: Kind of hackish way to ensure synchronized re-drawing - private synchronized void forceredraw() { - doLayout(); - } - /* * Methods for java.applet.AppletContext */ @@ -861,19 +771,14 @@ PluginDebug.debug("getCachedImageRef() got URL = ", url); PluginDebug.debug("getCachedImageRef() plugin codebase = ", codeBase); - // try to fetch it locally - if (panel instanceof NetxPanel) { + String resourceName = originalURL.substring(codeBase.length()); + JNLPClassLoader loader = (JNLPClassLoader) panel.getAppletClassLoader(); - URL localURL = null; + URL localURL = null; + if (loader.resourceAvailableLocally(resourceName)) + url = loader.getResource(resourceName); - String resourceName = originalURL.substring(codeBase.length()); - JNLPClassLoader loader = (JNLPClassLoader) ((NetxPanel) panel).getAppletClassLoader(); - - if (loader.resourceAvailableLocally(resourceName)) - localURL = loader.getResource(resourceName); - - url = localURL != null ? localURL : url; - } + url = localURL != null ? localURL : url; } PluginDebug.debug("getCachedImageRef() getting img from URL = ", url); @@ -900,7 +805,7 @@ imageRefs.clear(); } - private static Vector appletPanels = new Vector(); + private static Vector appletPanels = new Vector(); /** * Get an applet by name. @@ -910,8 +815,8 @@ SocketPermission panelSp = new SocketPermission(panel.getCodeBase().getHost(), "connect"); synchronized(appletPanels) { - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { - AppletPanel p = (AppletPanel) e.nextElement(); + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { + AppletPanel p = e.nextElement(); String param = p.getParameter("name"); if (param != null) { param = param.toLowerCase(); @@ -941,7 +846,7 @@ new SocketPermission(panel.getCodeBase().getHost(), "connect"); synchronized(appletPanels) { - for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { + for (Enumeration e = appletPanels.elements(); e.hasMoreElements();) { AppletPanel p = e.nextElement(); if (p.getDocumentBase().equals(panel.getDocumentBase())) { @@ -1591,15 +1496,15 @@ * at the same time. */ try { - panel.joinAppletThread(); - panel.release(); + ((AppletViewerPanel)panel).joinAppletThread(); + ((AppletViewerPanel)panel).release(); } catch (InterruptedException e) { return; // abort the reload } AccessController.doPrivileged(new PrivilegedAction() { public Void run() { - panel.createAppletThread(); + ((AppletViewerPanel)panel).createAppletThread(); return null; } }); @@ -1652,34 +1557,32 @@ // final AppletPanel p = panel; - new Thread(new Runnable() - { - public void run() - { - ClassLoader cl = p.applet.getClass().getClassLoader(); - - // Since we want to deal with JNLPClassLoader, extract it if this - // is a codebase loader - if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) - cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); + new Thread(new Runnable() { + @SuppressWarnings("deprecation") + public void run() { + ClassLoader cl = p.applet.getClass().getClassLoader(); - ThreadGroup tg = ((JNLPClassLoader) cl).getApplication().getThreadGroup(); + // Since we want to deal with JNLPClassLoader, extract it if this + // is a codebase loader + if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) + cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); - appletShutdown(p); - appletPanels.removeElement(p); - dispose(); + ThreadGroup tg = ((JNLPClassLoader) cl).getApplication().getThreadGroup(); - if (tg.activeCount() > 0) - tg.stop(); + appletShutdown(p); + appletPanels.removeElement(p); + dispose(); - if (countApplets() == 0) { - appletSystemExit(); - } + if (tg.activeCount() > 0) + tg.stop(); - updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); - } - }).start(); + if (countApplets() == 0) { + appletSystemExit(); + } + updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); + } + }).start(); } /** @@ -1868,6 +1771,7 @@ }); From dlila at redhat.com Thu Apr 14 09:22:17 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 12:22:17 -0400 (EDT) Subject: [RFC][plugin]: fix concurrency problems in PAV.java In-Reply-To: <20110414161259.GE9899@redhat.com> Message-ID: <70095251.306600.1302798137628.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > The ChangeLog in the patch has a line over 80 chars. > > Assuming the only change between this and the last patch I reviewed is > the change of the vector type, OK for commit after fixing the > ChangeLog. It is. I fixed the 80 char problem and pushed it. Thanks for the review. Denis. ----- Original Message ----- > * Denis Lila [2011-04-14 12:02]: > > > Ok. > > > I attached the patch with the updated ChangeLog. > > > > *sigh*, _now_ I attached the patch. > > > > > Thanks, > Deepak > > > ----- Original Message ----- > > > > > Do you still think I should change it to NetxPanel? > > > > Yes please. > > > > > > > > > > > Regards, > > > Denis. > > > > > > ----- Original Message ----- > > > > * Denis Lila [2011-04-14 11:43]: > > > > > > It is not irrelevant to strongly type a container. > > > > > > > > > > What I meant by irrelevant is that NetxPanel is a subclass, so > > > > > it > > > > > adds to the implementation of AppletPanel. We don't need any > > > ... > > > diff -r c84f2e5b039f ChangeLog > > --- a/ChangeLog Wed Apr 13 12:18:38 2011 -0400 > > +++ b/ChangeLog Thu Apr 14 12:05:10 2011 -0400 > > @@ -1,3 +1,21 @@ > > +2011-04-14 Denis Lila > > + > > + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > + Remove unused imports, added various SuppressWarnings annotations. > > + (createPanel): Return NetxPanel from doPriviledged. Remove dead > > code. > > + (PluginParseRequest): Remove - unused. > > + (defaultSaveFile, label, statusMsgStream, requests, handle): > > Remove - unused. > > + (panel): Make NetxPanel. > > + (identifier, appletPanels): Privatize. > > + (appletPanels): Change type to NetxPanel. > > + (applets, status): Use ConcurrentHashMaps. > > + (framePanel, PluginAppletViewer): Remove unused PrintStream > > argument. > > + (forceredraw): Remove - unused. > > + (getApplets): Use generics. > > + (appletClose): Fix style to match our convention. > > + (destroyApplet): Use pav instead of calling get many times. > > + (splitSeparator): Remove. Replace uses by String.split(). > > + > > 2011-04-12 Denis Lila > > > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > diff -r c84f2e5b039f > > plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed > > Apr 13 12:18:38 2011 -0400 > > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu > > Apr 14 12:05:10 2011 -0400 > > @@ -70,23 +70,19 @@ > > import java.awt.Graphics; > > import java.awt.Image; > > import java.awt.Insets; > > -import java.awt.Label; > > import java.awt.Toolkit; > > import java.awt.event.WindowAdapter; > > import java.awt.event.WindowEvent; > > import java.awt.event.WindowListener; > > import java.awt.print.PageFormat; > > import java.awt.print.Printable; > > -import java.io.BufferedReader; > > import java.io.IOException; > > import java.io.InputStream; > > -import java.io.InputStreamReader; > > import java.io.PrintStream; > > import java.io.Reader; > > import java.io.StringReader; > > import java.io.UnsupportedEncodingException; > > import java.lang.reflect.InvocationTargetException; > > -import java.net.MalformedURLException; > > import java.net.SocketPermission; > > import java.net.URI; > > import java.net.URL; > > @@ -128,49 +124,27 @@ > > long handle, int x, int y, > > final URL doc, > > final Hashtable > > atts) { > > - AppletViewerPanel panel = AccessController.doPrivileged(new > > PrivilegedAction() { > > - public AppletViewerPanel run() { > > - try { > > - AppletViewerPanel panel = new NetxPanel(doc, atts, false); > > - AppletViewerPanel.debug("Using NetX panel"); > > - PluginDebug.debug(atts.toString()); > > - return panel; > > - } catch (Exception ex) { > > - AppletViewerPanel.debug("Unable to start NetX applet - defaulting > > to Sun applet", ex); > > - return new AppletViewerPanel(doc, atts); > > - } > > + NetxPanel panel = AccessController.doPrivileged(new > > PrivilegedAction() { > > + public NetxPanel run() { > > + NetxPanel panel = new NetxPanel(doc, atts, false); > > + NetxPanel.debug("Using NetX panel"); > > + PluginDebug.debug(atts.toString()); > > + return panel; > > } > > }); > > > > // create the frame. > > - PluginAppletViewer.framePanel(identifier, System.out, handle, > > panel); > > + PluginAppletViewer.framePanel(identifier, handle, panel); > > > > panel.init(); > > > > // Start the applet > > initEventQueue(panel); > > > > - // Applet initialized. Find out it's classloader and add it to the > > list > > - String portComponent = doc.getPort() != -1 ? ":" + doc.getPort() : > > ""; > > - String codeBase = doc.getProtocol() + "://" + doc.getHost() + > > portComponent; > > - > > - if (atts.get("codebase") != null) { > > - try { > > - URL appletSrcURL = new URL(codeBase + atts.get("codebase")); > > - codeBase = appletSrcURL.getProtocol() + "://" + > > appletSrcURL.getHost(); > > - } catch (MalformedURLException mfue) { > > - // do nothing > > - } > > - } > > - > > - // Wait for the panel to initialize > > - // (happens in a separate thread) > > - Applet a; > > - > > // Wait for panel to come alive > > int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait > > for panel to come alive > > int wait = 0; > > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait > > < maxWait)) { > > + while (!panel.isAlive() && wait < maxWait) { > > try { > > Thread.sleep(50); > > wait += 50; > > @@ -181,12 +155,12 @@ > > > > // Wait for the panel to initialize > > // (happens in a separate thread) > > - PluginAppletViewer.waitForAppletInit((NetxPanel) panel); > > + PluginAppletViewer.waitForAppletInit(panel); > > > > - a = panel.getApplet(); > > + Applet a = panel.getApplet(); > > > > // Still null? > > - if (panel.getApplet() == null) { > > + if (a == null) { > > streamhandler.write("instance " + identifier + " > > reference " + -1 + " fatalError " + "Initialization > > failed"); > > return null; > > } > > @@ -194,8 +168,8 @@ > > PluginDebug.debug("Applet ", a.getClass(), " initialized"); > > streamhandler.write("instance " + identifier + " reference > > 0 initialized"); > > > > - > > AppletSecurityContextManager.getSecurityContext(0).associateSrc(((NetxPanel) > > panel).getAppletClassLoader(), doc); > > - > > AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, > > ((NetxPanel) panel).getAppletClassLoader()); > > + > > AppletSecurityContextManager.getSecurityContext(0).associateSrc(panel.getAppletClassLoader(), > > doc); > > + > > AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, > > panel.getAppletClassLoader()); > > > > return panel; > > } > > @@ -231,7 +205,7 @@ > > > > // The list of events that will be executed is provided > > as a > > // ","-separated list. No error-checking will be done > > on the list. > > - String[] events = splitSeparator(",", eventList); > > + String[] events = eventList.split(","); > > > > for (int i = 0; i < events.length; i++) { > > PluginDebug.debug("Adding event to queue: ", > > events[i]); > > @@ -260,52 +234,14 @@ > > ; > > } > > } > > - > > - /** > > - * Split a string based on the presence of a specified separator. > > Returns > > - * an array of arbitrary length. The end of each element in the > > array is > > - * indicated by the separator of the end of the string. If there is > > a > > - * separator immediately before the end of the string, the final > > element > > - * will be empty. None of the strings will contain the separator. > > Useful > > - * when separating strings such as "foo/bar/bas" using separator > > "/". > > - * > > - * @param sep The separator. > > - * @param s The string to split. > > - * @return An array of strings. Each string in the array is > > determined > > - * by the location of the provided sep in the original string, > > - * s. Whitespace not stripped. > > - */ > > - private String[] splitSeparator(String sep, String s) { > > - List l = new ArrayList(); > > - int tokenStart = 0; > > - int tokenEnd = 0; > > - > > - while ((tokenEnd = s.indexOf(sep, tokenStart)) != -1) { > > - l.add(s.substring(tokenStart, tokenEnd)); > > - tokenStart = tokenEnd + 1; > > - } > > - // Add the final element. > > - l.add(s.substring(tokenStart)); > > - > > - return l.toArray(new String[l.size()]); > > - } > > -} > > - > > -class PluginParseRequest { > > - long handle; > > - String tag; > > - String documentbase; > > } > > > > /* > > */ > > // FIXME: declare JSProxy implementation > > + at SuppressWarnings("serial") > > public class PluginAppletViewer extends XEmbeddedFrame > > implements AppletContext, Printable { > > - /** > > - * Some constants... > > - */ > > - private static String defaultSaveFile = "Applet.ser"; > > > > /** > > * Enumerates the current status of an applet > > @@ -323,23 +259,9 @@ > > /** > > * The panel in which the applet is being displayed. > > */ > > - AppletViewerPanel panel; > > + private NetxPanel panel; > > > > - /** > > - * The status line. > > - */ > > - Label label; > > - > > - /** > > - * output status messages to this stream > > - */ > > - > > - PrintStream statusMsgStream; > > - > > - int identifier; > > - > > - private static HashMap requests = > > - new HashMap(); > > + private int identifier; > > > > // Instance identifier -> PluginAppletViewer object. > > private static ConcurrentMap > > applets = > > @@ -352,7 +274,6 @@ > > private static ConcurrentMap status = > > new ConcurrentHashMap(); > > > > - private long handle = 0; > > private WindowListener windowEventListener = null; > > private AppletEventListener appletEventListener = null; > > > > @@ -370,15 +291,14 @@ > > public PluginAppletViewer() { > > } > > > > - public static void framePanel(int identifier, PrintStream > > statusMsgStream, > > - long handle, AppletViewerPanel panel) { > > + public static void framePanel(int identifier, long handle, > > NetxPanel panel) { > > > > PluginDebug.debug("Framing ", panel); > > > > // SecurityManager MUST be set, and only privileged code > > may call reFrame() > > System.getSecurityManager().checkPermission(new > > AllPermission()); > > > > - PluginAppletViewer appletFrame = new PluginAppletViewer(handle, > > identifier, statusMsgStream, panel); > > + PluginAppletViewer appletFrame = new PluginAppletViewer(handle, > > identifier, panel); > > > > appletFrame.add("Center", panel); > > appletFrame.pack(); > > @@ -395,11 +315,9 @@ > > * Create new plugin appletviewer frame > > */ > > private PluginAppletViewer(long handle, final int identifier, > > - PrintStream statusMsgStream, > > - AppletViewerPanel appletPanel) { > > + NetxPanel appletPanel) { > > > > super(handle, true); > > - this.statusMsgStream = statusMsgStream; > > this.identifier = identifier; > > this.panel = appletPanel; > > > > @@ -547,13 +465,11 @@ > > if (wait >= maxWait) > > throw new Exception("Applet initialization > > timeout"); > > > > - PluginAppletViewer oldFrame = applets.get(identifier); > > - > > // We should not try to destroy an applet during > > // initialization. It may cause an inconsistent > > state, > > // which would bad if it's a trusted applet that > > // read/writes to files > > - waitForAppletInit((NetxPanel) applets.get(identifier).panel); > > + waitForAppletInit(applets.get(identifier).panel); > > > > // Should we proceed with reframing? > > if (updateStatus(identifier, > > PAV_INIT_STATUS.REFRAME_COMPLETE).equals(PAV_INIT_STATUS.INACTIVE)) > > { > > @@ -660,25 +576,25 @@ > > PluginDebug.debug("Attempting to destroy frame ", > > identifier); > > > > // Try to dispose the panel right away > > - PluginAppletViewer pav = applets.get(identifier); > > - if (pav != null) > > + final PluginAppletViewer pav = applets.get(identifier); > > + if (pav != null) { > > pav.dispose(); > > > > - // If panel is already disposed, return > > - if (applets.get(identifier).panel.applet == null) { > > - PluginDebug.debug(identifier, " panel inactive. Returning."); > > - return; > > + // If panel is already disposed, return > > + if (pav.panel.applet == null) { > > + PluginDebug.debug(identifier, " panel inactive. Returning."); > > + return; > > + } > > + > > + PluginDebug.debug("Attempting to destroy panel ", identifier); > > + > > + SwingUtilities.invokeLater(new Runnable() { > > + public void run() { > > + pav.appletClose(); > > + } > > + }); > > } > > > > - PluginDebug.debug("Attempting to destroy panel ", identifier); > > - > > - final int fIdentifier = identifier; > > - SwingUtilities.invokeLater(new Runnable() { > > - public void run() { > > - applets.get(fIdentifier).appletClose(); > > - } > > - }); > > - > > PluginDebug.debug(identifier, " destroyed"); > > } > > > > @@ -729,8 +645,7 @@ > > final int height = Integer.parseInt(dimMsg[3]); > > final int width = Integer.parseInt(dimMsg[1]); > > > > - if (panel instanceof NetxPanel) > > - ((NetxPanel) panel).updateSizeInAtts(height, width); > > + panel.updateSizeInAtts(height, width); > > > > try { > > SwingUtilities.invokeAndWait(new Runnable() { > > @@ -775,7 +690,7 @@ > > // Wait for panel to come alive > > int maxWait = APPLET_TIMEOUT; // wait for panel to come > > alive > > int wait = 0; > > - while ((panel == null) || (!((NetxPanel) panel).isAlive() && wait > > < maxWait)) { > > + while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { > > try { > > Thread.sleep(50); > > wait += 50; > > @@ -786,13 +701,13 @@ > > > > // Wait for the panel to initialize > > // (happens in a separate thread) > > - waitForAppletInit((NetxPanel) panel); > > + waitForAppletInit(panel); > > > > - PluginDebug.debug(panel, " -- ", panel.getApplet(), " -- ", > > ((NetxPanel) panel).isAlive()); > > + PluginDebug.debug(panel, " -- ", panel.getApplet(), " -- ", > > panel.isAlive()); > > > > // Still null? > > if (panel.getApplet() == null) { > > - this.streamhandler.write("instance " + identifier + " reference " > > + -1 + " fatalError " + "Initialization failed"); > > + streamhandler.write("instance " + identifier + " reference " + -1 > > + " fatalError " + "Initialization failed"); > > return; > > } > > > > @@ -807,11 +722,6 @@ > > } > > } > > > > - // FIXME: Kind of hackish way to ensure synchronized re-drawing > > - private synchronized void forceredraw() { > > - doLayout(); > > - } > > - > > /* > > * Methods for java.applet.AppletContext > > */ > > @@ -861,19 +771,14 @@ > > PluginDebug.debug("getCachedImageRef() got URL = ", > > url); > > PluginDebug.debug("getCachedImageRef() plugin > > codebase = ", codeBase); > > > > - // try to fetch it locally > > - if (panel instanceof NetxPanel) { > > + String resourceName = originalURL.substring(codeBase.length()); > > + JNLPClassLoader loader = (JNLPClassLoader) > > panel.getAppletClassLoader(); > > > > - URL localURL = null; > > + URL localURL = null; > > + if (loader.resourceAvailableLocally(resourceName)) > > + url = loader.getResource(resourceName); > > > > - String resourceName = originalURL.substring(codeBase.length()); > > - JNLPClassLoader loader = (JNLPClassLoader) ((NetxPanel) > > panel).getAppletClassLoader(); > > - > > - if (loader.resourceAvailableLocally(resourceName)) > > - localURL = loader.getResource(resourceName); > > - > > - url = localURL != null ? localURL : url; > > - } > > + url = localURL != null ? localURL : url; > > } > > > > PluginDebug.debug("getCachedImageRef() getting img from > > URL = ", url); > > @@ -900,7 +805,7 @@ > > imageRefs.clear(); > > } > > > > - private static Vector appletPanels = new > > Vector(); > > + private static Vector appletPanels = new > > Vector(); > > > > /** > > * Get an applet by name. > > @@ -910,8 +815,8 @@ > > SocketPermission panelSp = > > new SocketPermission(panel.getCodeBase().getHost(), > > "connect"); > > synchronized(appletPanels) { > > - for (Enumeration e = appletPanels.elements(); > > e.hasMoreElements();) { > > - AppletPanel p = (AppletPanel) e.nextElement(); > > + for (Enumeration e = appletPanels.elements(); > > e.hasMoreElements();) { > > + AppletPanel p = e.nextElement(); > > String param = p.getParameter("name"); > > if (param != null) { > > param = param.toLowerCase(); > > @@ -941,7 +846,7 @@ > > new SocketPermission(panel.getCodeBase().getHost(), > > "connect"); > > > > synchronized(appletPanels) { > > - for (Enumeration e = appletPanels.elements(); > > e.hasMoreElements();) { > > + for (Enumeration e = appletPanels.elements(); > > e.hasMoreElements();) { > > AppletPanel p = e.nextElement(); > > if > > (p.getDocumentBase().equals(panel.getDocumentBase())) > > { > > > > @@ -1591,15 +1496,15 @@ > > * at the same time. > > */ > > try { > > - panel.joinAppletThread(); > > - panel.release(); > > + ((AppletViewerPanel)panel).joinAppletThread(); > > + ((AppletViewerPanel)panel).release(); > > } catch (InterruptedException e) { > > return; // abort the reload > > } > > > > AccessController.doPrivileged(new PrivilegedAction() > > { > > public Void run() { > > - panel.createAppletThread(); > > + ((AppletViewerPanel)panel).createAppletThread(); > > return null; > > } > > }); > > @@ -1652,34 +1557,32 @@ > > // > > final AppletPanel p = panel; > > > > - new Thread(new Runnable() > > - { > > - public void run() > > - { > > - ClassLoader cl = p.applet.getClass().getClassLoader(); > > - > > - // Since we want to deal with JNLPClassLoader, extract it if this > > - // is a codebase loader > > - if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > > - cl = ((JNLPClassLoader.CodeBaseClassLoader) > > cl).getParentJNLPClassLoader(); > > + new Thread(new Runnable() { > > + @SuppressWarnings("deprecation") > > + public void run() { > > + ClassLoader cl = p.applet.getClass().getClassLoader(); > > > > - ThreadGroup tg = ((JNLPClassLoader) > > cl).getApplication().getThreadGroup(); > > + // Since we want to deal with JNLPClassLoader, extract it if this > > + // is a codebase loader > > + if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > > + cl = ((JNLPClassLoader.CodeBaseClassLoader) > > cl).getParentJNLPClassLoader(); > > > > - appletShutdown(p); > > - appletPanels.removeElement(p); > > - dispose(); > > + ThreadGroup tg = ((JNLPClassLoader) > > cl).getApplication().getThreadGroup(); > > > > - if (tg.activeCount() > 0) > > - tg.stop(); > > + appletShutdown(p); > > + appletPanels.removeElement(p); > > + dispose(); > > > > - if (countApplets() == 0) { > > - appletSystemExit(); > > - } > > + if (tg.activeCount() > 0) > > + tg.stop(); > > > > - updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); > > - } > > - }).start(); > > + if (countApplets() == 0) { > > + appletSystemExit(); > > + } > > > > + updateStatus(identifier, PAV_INIT_STATUS.DESTROYED); > > + } > > + }).start(); > > } > > > > /** > > @@ -1868,6 +1771,7 @@ > > }); > > } > > > > + @SuppressWarnings("unused") > > public static void parse(int identifier, long handle, String > > width, > > String height, Reader in, URL url, > > PrintStream statusMsgStream, From dlila at redhat.com Thu Apr 14 10:54:01 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 13:54:01 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1432594239.25238.1302546039633.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1153604639.312729.1302803641208.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. You forgot to hg add CacheLRUWrapper. Assuming it was just a rename of the corresponding file in the previous version of your patch, I added it to your patch, and attached it. The attached patch should compile. Here are some things that jump out at me (more comments may come later on): In getCacheFileIfExists, can you put the lastPath computation in it's own function (similar to getIdForCacheFolder). That way it'll be a bit easier to figure out what's going on. In removeUntrackedDirectories you do + for (File f : temp.listFiles()) { + String path = f.getPath(); + temp = new File(path); + if (temp.isDirectory() && !keep.contains(temp.getPath())) { + try { + FileUtils.recursiveDelete(temp, temp); Wouldn't it be the same (and simpler) to do: + for (File f : temp.listFiles()) { + if (f.isDirectory() && !keep.contains(f.getPath())) { + try { + FileUtils.recursiveDelete(f, f); Also, the HashSet argument of that function is called "keep". This is a bit peculiar, since you're deleting everything in it. Also, can you make that a Set instead of HashSet? Most importantly: > I have applied your patch and did some adjustments such as using the > hash of the url as file name instead of having a really long > directory. Isn't this broken? I mean, what happens when two different urls hash to the same code? To me, it seems like you're just going to create a file when it is first hashed, and when a different URL has the same hash getCachFileIfExist will return the first cached file, instead of creating a new one. Regards, Denis. ----- Original Message ----- > Hi, > > > Questions? Comments? > > Cheers, > Andrew > > ----- Original Message ----- > > Hi Andrew. > > > > I've been looking over this. Rather than saying what I > > don't like, I committed your patch to a local repository > > and changed whatever I didn't like. It's much easier to > > express what changes I would like to see in Java than > > in English ;-). I've attached the patch with my changes, > > so in this e-mail I'll just give reasons for those changes. > > > > A lot of it is pretty minor things (like turning > > "if (e) return false;" into "if (e)\n return false"). > > Feel free to ignore those stylistic kind of changes. > > > > The other changes are: > > Adding a "," between the time and the folder identifier > > in the RecentlyUsed file. > > > > CacheLRUPolicy: enums are better for singletons. Also, if > > we have a singleton it's not so good to have many static > > fields because if ever we needed more than one instance > > of that class, the synchronized access to the static data > > structures would break. > > > > CacheLRUPolicy.updateEntry: the changes here save us a > > "substring" call, and it's slightly easier to read. > > > > getSortedKeys is now called getLRUSortedEntries. This was > > the biggest change and the reasons for it were: > > 1) We already have enough map iterations of the form: > > for key in keyset: value = map.getvalue(key) > > We shouldn't add to these. Iterating over (key, value) > > entries is better. > > 2) It's better to return the entries in the order that > > we want to use them, rather than iterating backwards. > > 3) We want to sort by the last updated time, so it's a > > good idea to turn the strings into longs first. Comparing > > strings might be correct (for now), but it's only > > correct by coincidence, and that should be avoided. > > > > Regards, > > Denis. > > > > ----- Original Message ----- > > > ----- Original Message ----- > > > > On 04/04/2011 05:45 PM, Andrew Su wrote: > > > > >>> I think this patch would be easier to review if you split it > > > > >>> into > > > > >>> two patches - one to fix problems with files being > > > > >>> overwritten, > > > > >>> and another to enforce cache sizes. > > > > > I've removed the section which will ensure the cache limit. > > > > > Will > > > > > post > > > > > that later. > > > > > > > > > > > > > Thanks! > > > > > > > > > + /** > > > > > + * This will return a File pointing to the location of cache > > > > > item. > > > > > + * @param urlPath Path of cache item within cache directory. > > > > > + * @return File if we have searched before, null otherwise. > > > > > + */ > > > > > + private static File getCacheFileIfExist(File urlPath){ > > > > > > > > > > > > Instead of nitpicking, I am going to ask you to post some > > > > information > > > > about the files added/modified. I missed this during the > > > > original > > > > review > > > > (I suppose that might be a code smell and we need to do some > > > > refactoring), but now I see that this patch introduces and/or > > > > modifies > > > > a > > > > number of files: RecentlyUsed, per cache-entry directory, and > > > > possibly > > > > more metadata. Could you please describe what the overall design > > > > of > > > > this > > > > cache is? What data each file contains? And in what format? > > > > > > File: > > > /RecentlyUsed > > > Desc: > > > Keep track of the most recently accessed file. It can work without > > > this file if we traverse the directory for this information. > > > Format: > > > This file is kept to how a regular properties file works > > > Key=Value > > > The Key consist of time accessed followed by the folder number. > > > Example: > > > 13020173404=/4/http/www.example.come/example.jar > > > In this case the 4 at the end is the cache directory. > > > > > > > > > File: > > > /////*.info > > > Desc: > > > These files contain information about the file in the directory. > > > Such as file length(size), last-modified header from download, and > > > whether this file should be deleted at shutdown. > > > Format: > > > Each line consist of a Key=Value pair to report the state of the > > > item. > > > > > > > > > The above mentioned files are the only ones that we change. > > > > > > Design: > > > It works similarly to the old cache with the addition of LRU and > > > separate per cache-entry directory. > > > During the initialization of the resource stage > > > (ResourceTracker.initializeResource()) Here we will try and grab > > > the most recently downloaded version of the cache-entry. If this > > > entry does not exist it will prepare a directory to store this > > > item. Now, to prevent another instance of plugin/javaws from > > > overwriting the file we lock the PropertiesFile associated with > > > this entry. If this file does exist, but not up to date then we > > > create a new directory to store the new file. The old entry is > > > marked for deletion at shutdown. > > > > > > Onto the downloading stage. This only happens if we have found > > > the entry to be outdated or does not exist (from above). In here > > > we try to lock on the PropertiesFile, and block if it is either > > > being requested, or already in downloading progress. It is okay > > > to block here because if there is a download for this file in > > > progress, we can't use it until it is completed anyways. > > > > > > Loading the jars... nothing changed here. > > > > > > JVM Shutdown. At this point we will remove all compressed > > > downloads and the folders they extract to since the check for > > > size difference will always be true, it will try to redownload > > > anyways. This can save some space at the end of the day. > > > After removing these entries, it will proceed to removing all > > > folders not being tracked by RecentlyUsed. (To get rid of the > > > currently cached items before patch). > > > > > > > > > > > I would love it if the response consists of patch with a new > > > > class > > > > per > > > > file/directory introduced/modified/repurposed and each class > > > > contains > > > > (as comments) the purpose and format :D > > > > > > I've move the policy to it's own class. Where it will handle the > > > > > > I've refactored the managing of the LRU policy into its own class. > > > However modifying info class will not be moved anywhere since that > > > is already handled by CacheEntry. The directories being created > > > didn't seem to fit to be its own class either, can not pass it > > > onto other plugin/javaws instances without having to traverse > > > the directories (I wanted to avoid that). > > > > > > Cheers, > > > Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: asu_cache_v2.patch Type: text/x-patch Size: 30850 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110414/7f421089/asu_cache_v2.patch From dbhole at redhat.com Thu Apr 14 11:29:08 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 14:29:08 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414150415.GB9899@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <4DA70B10.4030801@redhat.com> <20110414150415.GB9899@redhat.com> Message-ID: <20110414182908.GF9899@redhat.com> * Deepak Bhole [2011-04-14 11:05]: > * Omair Majid [2011-04-14 10:56]: > > On 04/14/2011 01:56 AM, Deepak Bhole wrote: > > Ah, neat. I didn't know that. I will make the change. > New patch attached. It uses nanoTime(). I've also expanded the synchronize block to include updates to the applets and status maps. To address Jiri's concern: since we are working with differences, negative return of nanoTime() won't matter as long as it is consistent, which the docs say it is. Updated ChangeLog: 2011-04-14 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (createPanel): use Object.wait() to wait, rather than pariodic sleep. (APPLET_TIMEOUT): Updated to be in nanoseconds. (framePanel): Synchronize put and notify threads waiting on the applets map instance. (appletStateChanged): Notify all threads waiting on the panel that just changed state. (handleMessage): Use the new waitTillTimeout function to wait, rather than periodically waking up. Improved timeout error string sent back. (updateStatus): Synchronize put and notify all threads waiting on status map. (waitForAppletInit): Use the new waitTillTimeout function to wait, rather than periodically waking up. (waitTillTimeout): New function. For a given non-null object, waits until the specified timeout, or, if an interrupt was thrown during wait, returns immediately. Cheers, Deepak -------------- next part -------------- diff -r 2ef65ff10619 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Wed Apr 13 19:17:21 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 14:17:06 2011 -0400 @@ -91,12 +91,10 @@ import java.security.PrivilegedAction; import java.security.PrivilegedActionException; import java.security.PrivilegedExceptionAction; -import java.util.ArrayList; import java.util.Enumeration; import java.util.HashMap; import java.util.Hashtable; import java.util.Iterator; -import java.util.List; import java.util.Map; import java.util.Vector; import java.util.concurrent.ConcurrentHashMap; @@ -142,14 +140,19 @@ initEventQueue(panel); // Wait for panel to come alive - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while (!panel.isAlive() && wait < maxWait) { - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + // Wait implemented the long way so that + // PluginAppletViewer.waitTillTimeout() needn't be exposed. + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; + + synchronized(panel) { + while (!panel.isAlive() && maxTimeToSleep > 0) { + long sleepStart = System.nanoTime(); + + try { + panel.wait(maxTimeToSleep); + } catch (InterruptedException e) {} // Just loop back + + maxTimeToSleep -= System.nanoTime() - sleepStart; } } @@ -161,7 +164,7 @@ // Still null? if (a == null) { - streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); + streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError: " + "Initialization timed out"); return null; } @@ -277,7 +280,7 @@ private WindowListener windowEventListener = null; private AppletEventListener appletEventListener = null; - public static final int APPLET_TIMEOUT = 180000; + public static final long APPLET_TIMEOUT = 180000000000L; // 180s in ns private static final Object requestMutex = new Object(); private static long requestIdentityCounter = 0L; @@ -306,7 +309,11 @@ appletFrame.appletEventListener = new AppletEventListener(appletFrame, appletFrame); panel.addAppletListener(appletFrame.appletEventListener); - applets.put(identifier, appletFrame); + + synchronized(applets) { + applets.put(identifier, appletFrame); + applets.notifyAll(); + } PluginDebug.debug(panel, " framed"); } @@ -357,6 +364,10 @@ public void appletStateChanged(AppletEvent evt) { AppletPanel src = (AppletPanel) evt.getSource(); + synchronized (src) { + src.notifyAll(); + } + switch (evt.getID()) { case AppletPanel.APPLET_RESIZE: { if (src != null) { @@ -448,21 +459,16 @@ new StringReader(tag), new URL(documentBase)); - int maxWait = APPLET_TIMEOUT; // wait for applet to fully load - int wait = 0; - while (!applets.containsKey(identifier) && // Map is populated only by reFrame - (wait < maxWait)) { - - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + long maxTimeToSleep = APPLET_TIMEOUT; + synchronized(applets) { + while (!applets.containsKey(identifier) && + maxTimeToSleep > 0) { // Map is populated only by reFrame + maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); } } // If wait exceeded maxWait, we timed out. Throw an exception - if (wait >= maxWait) + if (maxTimeToSleep <= 0) throw new Exception("Applet initialization timeout"); // We should not try to destroy an applet during @@ -546,7 +552,11 @@ } // Else set to given status - status.put(identifier, newStatus); + + synchronized(status) { + status.put(identifier, newStatus); + status.notifyAll(); + } return prev; } @@ -599,25 +609,23 @@ } /** - * Function to block until applet initialization is complete + * Function to block until applet initialization is complete. + * + * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} * * @param panel the instance to wait for. */ public static void waitForAppletInit(NetxPanel panel) { - int waitTime = 0; + // Wait till initialization finishes + long maxTimeToSleep = APPLET_TIMEOUT; - // Wait till initialization finishes - while (panel.getApplet() == null && - panel.isAlive() && - waitTime < APPLET_TIMEOUT) { - try { - if (waitTime % 500 == 0) - PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); - - Thread.sleep(waitTime += 50); - } catch (InterruptedException ie) { - // just wait + synchronized(panel) { + while (panel.getApplet() == null && + panel.isAlive() && + maxTimeToSleep > 0) { + PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); } } @@ -628,14 +636,11 @@ if (message.startsWith("width")) { // Wait for panel to come alive - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && wait < maxWait) { - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + long maxTimeToSleep = APPLET_TIMEOUT; + synchronized(status) { + while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && + maxTimeToSleep > 0) { + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); } } @@ -686,17 +691,21 @@ // FIXME: how do we determine what security context this // object should belong to? Object o; - - // Wait for panel to come alive - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { + + // First, wait for panel to instantiate + int waited = 0; + while (panel == null && waited < APPLET_TIMEOUT) { try { Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait - } + waited += 50; + } catch (InterruptedException ie) {} // discard, loop back + } + + // Next, wait for panel to come alive + long maxTimeToSleep = APPLET_TIMEOUT; + synchronized(panel) { + while (!panel.isAlive()) + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); } // Wait for the panel to initialize @@ -707,7 +716,7 @@ // Still null? if (panel.getApplet() == null) { - streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); + streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError: " + "Initialization timed out"); return; } @@ -2049,4 +2058,37 @@ // Draw the painted image g.drawImage(bufFrameImg, 0, 0, this); } + + /** + * Waits on a given object until timeout. + * + * This function assumes that the monitor lock has already been + * acquired by the caller. + * + * If the given object is null, this function returns immediately. + * + * @param obj The object to wait on + * @param timeout The maximum time to wait (nanoseconds) + * @return Approximate time spent sleeping (not guaranteed to be perfect) + */ + public static long waitTillTimeout(Object obj, long timeout) { + + // Can't wait on null. Return 0 indicating no wait happened. + if (obj == null) + return 0; + + // Record when we started sleeping + long sleepStart = 0L; + + // Convert timeout to ms since wait() takes ms + timeout = timeout >= 1000000 ? timeout/1000000 : 1; + + try { + sleepStart = System.nanoTime(); + obj.wait(timeout); + } catch (InterruptedException ie) {} // Discarded, time to return + + // Return the difference + return System.nanoTime() - sleepStart; + } } From dlila at redhat.com Thu Apr 14 11:47:00 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 14:47:00 -0400 (EDT) Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414132202.GA32038@redhat.com> Message-ID: <1416518579.313636.1302806820656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > I mentioned it in the comments, it is so that > PluginAppletViewer.waitTillTimeout() could remain private (the above > is in a > separate class). I intend to re-factor a lot of that code (already > started > working on it yesterday) that will address it there. In the mean time, > I > saw no harm in duplicating a few lines of code. Will you make the factory a static inner class in PAV? I think having two separate classes in the same file is pretty ugly. > > > - } catch (InterruptedException ie) { > > > - // just wait > > > + int maxTimeToSleep = APPLET_TIMEOUT; > > > + synchronized(status) { > > > + while > > > (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && > > > + maxTimeToSleep > 0) { > > > + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); > > > > Is status guaranteed to contain a mapping for identifier? > > > > Yes, it is. I never liked the existence of this "status" map. We need "applets" because we have static methods that have to have access to all PAV objects. status, on the other hand is just a way to associate some data with each PAV instance, but that's exactly what members are for. I think statuses should eventually become members, and updateStatus should stop being static (though not necessarily in this changeset). One more thing: I think it might be better to introduce 2-3 lock objects just for use with .wait and .notify. I don't think it's a very good idea to lock on status and applets because we don't know what kind of internal synchronization they use. It's generally safer to lock on private objects that only we have access to (and it also might reduce contention). Other than these minor things, I can't find anything wrong with the patch (that is, your new patch, with nano time). Regards, Denis. ----- Original Message ----- > * Dr Andrew John Hughes [2011-04-14 07:41]: > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > * Deepak Bhole [2011-04-13 20:48]: > > > > Hi, > > > > > > > > Andrew mentioned in one of the previous threads that the current > > > > plugin > > > > code waits in an inefficient manner. It wakes up periodically to > > > > check for conditions, and goes back to sleep, and keeps doing > > > > that > > > > cyclically. > > > > > > > > The attached patch uses a new function that uses object.wait for > > > > the object of interest. > From omajid at redhat.com Thu Apr 14 12:00:11 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Apr 2011 15:00:11 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414182908.GF9899@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <4DA70B10.4030801@redhat.com> <20110414150415.GB9899@redhat.com> <20110414182908.GF9899@redhat.com> Message-ID: <4DA7443B.4070307@redhat.com> On 04/14/2011 02:29 PM, Deepak Bhole wrote: > * Deepak Bhole [2011-04-14 11:05]: >> > * Omair Majid [2011-04-14 10:56]: >>> > > On 04/14/2011 01:56 AM, Deepak Bhole wrote: > >> > >> > Ah, neat. I didn't know that. I will make the change. >> > > New patch attached. It uses nanoTime(). > Just one concern, noted below. > @@ -142,14 +140,19 @@ > initEventQueue(panel); > > // Wait for panel to come alive > - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > - int wait = 0; > - while (!panel.isAlive()&& wait< maxWait) { > - try { > - Thread.sleep(50); > - wait += 50; > - } catch (InterruptedException ie) { > - // just wait > + // Wait implemented the long way so that > + // PluginAppletViewer.waitTillTimeout() needn't be exposed. > + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > + > + synchronized(panel) { > + while (!panel.isAlive()&& maxTimeToSleep> 0) { > + long sleepStart = System.nanoTime(); > + > + try { > + panel.wait(maxTimeToSleep); > + } catch (InterruptedException e) {} // Just loop back > + > + maxTimeToSleep -= System.nanoTime() - sleepStart; maxTimeToSleep is in ns, but wait expects ms. waitTillTimeout() converts the timeout in ns to ms before passing it to wait(). I think we should do something similar here. Everything else looks fine to me. Cheers, Omair From asu at redhat.com Thu Apr 14 12:32:38 2011 From: asu at redhat.com (Andrew Su) Date: Thu, 14 Apr 2011 15:32:38 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1153604639.312729.1302803641208.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <243738959.102984.1302809558541.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Denis Lila" > To: "Andrew Su" > Cc: "IcedTea" , "Omair Majid" > Sent: Thursday, April 14, 2011 1:54:01 PM > Subject: Re: [RFC][Icedtea-web]: Changed how cache works. > Hi. > > You forgot to hg add CacheLRUWrapper. Assuming it was just a > rename of the corresponding file in the previous version of > your patch, I added it to your patch, and attached it. The > attached patch should compile. Oops, thanks for doing that! > > Here are some things that jump out at me (more comments may come > later on): > > In getCacheFileIfExists, can you put the lastPath computation > in it's own function (similar to getIdForCacheFolder). That way > it'll be a bit easier to figure out what's going on. Sure. > > In removeUntrackedDirectories you do > > + for (File f : temp.listFiles()) { > + String path = f.getPath(); > + temp = new File(path); > + if (temp.isDirectory() && !keep.contains(temp.getPath())) { > + try { > + FileUtils.recursiveDelete(temp, temp); > > Wouldn't it be the same (and simpler) to do: > > + for (File f : temp.listFiles()) { > + if (f.isDirectory() && !keep.contains(f.getPath())) { > + try { > + FileUtils.recursiveDelete(f, f); > Yes it would; Residue from moving things around.. > Also, the HashSet argument of that function is called "keep". > This is a bit peculiar, since you're deleting everything in it. > Also, can you make that a Set instead of HashSet? Changed. > > > Most importantly: > > I have applied your patch and did some adjustments such as using the > > hash of the url as file name instead of having a really long > > directory. > > Isn't this broken? I mean, what happens when two different urls > hash to the same code? I think it might be best to hold this off for now, and hack at it later. This was an attempt to make it so that we don't have a bunch of folders with just another folder in it. > > To me, it seems like you're just going to create a file when it > is first hashed, and when a different URL has the same hash > getCachFileIfExist will return the first cached file, instead > of creating a new one. -- snip -- Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 201104014_cache_stuff_vXX.patch Type: text/x-patch Size: 31998 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110414/2c8b3eb7/201104014_cache_stuff_vXX.patch From dbhole at redhat.com Thu Apr 14 12:32:55 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 15:32:55 -0400 Subject: DBus font installs [incomplete] In-Reply-To: <154001230.347131.1299090878822.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <514115585.346074.1299088413470.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <154001230.347131.1299090878822.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110414193254.GH9899@redhat.com> Please re-post this patch with proper docs for all of the functions and comments on what the non-obvious lines of code are doing, especially when they call external API. Comments on generic issues below: * Andrew Su [2011-03-02 13:35]: > Hello, > > This patch is an attempt at requesting users to install a font that will allow them to display the text being rendered if the glyph is missing. It is still a work in progress. > > Known issues: > - Segmentation fault when rechecking for newly installed fonts to load. This is a showstopper. Nothing we add should make the JVM crash under any circumstances. > - If characters from different languages are being rendered one at a time it would constantly request user to install the languages not found. Can't we maintain a list and not ask back if the user said no once? > - May ask to install a non-standard language (unrecognised by packagekit). > What will packagekit try to install if it is non-standard? > Attached: > - addFontInstall.patch: This will add the patch and modify the Makefile accordingly. > - GlyphChecker.c: Used to create libglyphchecker.so (which should be placed in the openjdk's lib directory. > - GlyphChecker.h: Header for using jni. > > I used [on a x86_64 machine] > > gcc -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/include/ -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/include/linux/ -I/usr/include/dbus-1.0/ -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include -shared -fPIC -g -O0 -Wall -lfontconfig -ldbus-glib-1 -o libglyphchecker.so GlyphChecker.c > > to build the library file. (Replace with where your libs are..) once compiled, place the .so into your jre's lib dir. > ex: ${BUILD_DIR}/openjdk.build/j2sdk-image/jre/lib/amd64/ > > To test that it searches and installs fonts.. > You can run it as follows: > GlyphChecker.addMissing((char) 0x710); > GlyphChecker.doAll(); // This should return true if you accepted to install > > Please let me know if you see any issues with it. > ... > #include > #include > #include > > FcChar8* getSuperSet(FcLangSet* fls) { > // printf("Getting superset.\n"); > Above should be removed. As should all other uncommented printfs > FcChar8* s = NULL; > FcStrSet* ss = FcLangSetGetLangs(fls); > FcStrList* sl = FcStrListCreate(ss); > FcChar8* name = FcStrListNext(sl); > const FcCharSet* finalSet = NULL; > if (name != NULL) > finalSet = FcLangGetCharSet(name); > > while ((s = FcStrListNext(sl))) { > const FcCharSet* fs = FcLangGetCharSet(s); > if (FcCharSetIsSubset(finalSet, fs)) { > FcCharSetDestroy((FcCharSet*) finalSet); > finalSet = fs; > FcStrFree(name); > name = FcStrCopy(s); > } else { > FcCharSetDestroy((FcCharSet*) fs); > } > FcStrFree(s); Should you be freeing the string? Man page for FcStrListNext does not talk about caller having to free the return reference. ... ... > FcChar32* dst = (FcChar32*) malloc(sizeof(FcChar32) * 4); // This should be enough as UTF-32 uses 4 bytes to encode each character. > FcLangSet* completeSet = FcLangSetCreate(); > > // printf("Character is %s\n", characters); > // printf("Length: %d\n", FcUtf8ToUcs4((FcChar8*) characters, dst, len)); > FcUtf8ToUcs4((FcChar8*) characters, dst, len); > while ((s = FcStrListNext(sl))) { > const FcCharSet* fs = FcLangGetCharSet(s); > if (FcCharSetHasChar(fs, *dst)) { > // printf("Found in language %s\n", (char*) s); > FcLangSetAdd(completeSet, s); // Create our pool of languages that use this. > found = 1; > } > FcCharSetDestroy((FcCharSet*) fs); > } > dst is leaking memory as it is never freed. > FcStrListDone(sl); > FcStrSetDestroy(ss); > if (!found) { > // fprintf(stderr, "Font did not match any language's character set.\n"); > return NULL; > } > > return (char*) FcStrPlus((FcChar8*) ":lang=", getSuperSet(completeSet)); getSuperSet could return NULL (is this the SEGV you mentioned above?). > } > > JNIEXPORT jobjectArray JNICALL > Java_org_classpath_icedtea_font_GlyphChecker_getLangs(JNIEnv *env, > jobject self, jobjectArray sArr, jintArray iArr) { > > int i; > int len = (*env)->GetArrayLength(env, sArr); > jobjectArray ret = (*env)->NewObjectArray(env, len, (*env)->FindClass(env, > "java/lang/String"), NULL); > > jint *lens = (*env)->GetIntArrayElements(env, iArr, 0); > for (i = 0; i < len; i++) { > jstring s = (jstring)(*env)->GetObjectArrayElement(env, sArr, i); > > char* lang = checkChar(env, s, lens[i]); checkChar is allocating the memory for lang. lang is never freed though. ... ... > > connection = dbus_g_bus_get(DBUS_BUS_SESSION, NULL); Second param to dbus_g_bus_get is an error store. What if an error happens above? DBus may not be running in the bg. In fact if it isn't, we should return gracefully from here and just let the VM pick the font to draw. > proxy = dbus_g_proxy_new_for_name(connection, "org.freedesktop.PackageKit", > "/org/freedesktop/PackageKit", "org.freedesktop.PackageKit.Modify"); > > ret = dbus_g_proxy_call_with_timeout(proxy, "InstallFontconfigResources", > INT_MAX, &error, G_TYPE_UINT, 0, G_TYPE_STRV, asFont, > G_TYPE_STRING, "", G_TYPE_INVALID, G_TYPE_INVALID); > I think we should have a timeout rather than an infinite wait on user input. > free(asFont); > It is good practice to set a var (asFont above) to NULL after freeing. > if (!ret) { > g_warning("failed: %s", error->message); > g_error_free(error); > return 1; > } > return 0; > } > > JNIEXPORT jint JNICALL > Java_org_classpath_icedtea_font_GlyphChecker_libExist(JNIEnv *env, jobject self) { Perhaps we can extend this method to also check if dbus is running and if we can connect to it? That way we don't have to go through the pain of searching for a font unnecessarily. > diff -r 29c90e090d7b Makefile.am > --- a/Makefile.am Wed Mar 02 18:41:37 2011 +0100 > +++ b/Makefile.am Wed Mar 02 13:01:52 2011 -0500 > @@ -327,7 +327,8 @@ > patches/openjdk/6766342-AA-simple-shape-performance.patch \ > patches/openjdk/7016856-pisces-performance.patch \ > patches/openjdk/6934977-MappedByteBuffer.load.patch \ > - patches/jaxp-serial-version-uid.patch > + patches/jaxp-serial-version-uid.patch \ > + patches/fontinstall.patch > > if !WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ That patch should probably be renamed to something more descriptive. > ++ * > ++ * Do those will try it on > ++ * yum install wqy-unibit-fonts gnu-free-sans-fonts gnu-free-fonts-common -y > ++ * yum remove wqy-unibit-fonts gnu-free-sans-fonts gnu-free-fonts-common -y > ++ * Not sure what the above comment means :) > ++ * > ++ */ > ++public class GlyphChecker { > ++ private static final HashSet asked = new HashSet(); > ++ private static final HashSet pending = new HashSet(); > ++ private static final HashSet missingChars = new HashSet(); // Each entry should only be 1 character. Above could be modified from different threads can't they? Is so, consider using ConcurreptMap/ConcurrentHashMap or use Collections.synchronizedSet. > ++ private static SunGraphicsEnvironment sgEnv = null; > ++ private static HashSet temp = null; > ++ > ++ > ++ static { > ++ > ++ System.loadLibrary("glyphchecker"); > ++ > ++ > ++ > ++ } > ++ Why all the extra spaces? > ++ public static boolean doAll() { > ++ Do what all? Also, this is a publicly exposed method. Does it need to be? > ++ if (libExist() != 0) return false; > ++ getSunGraphicsEnvironment(); > ++ > ++ // We can also completely skip this, and not reask if they choose not to accept. > ++ switch (ret) { > ++ case 0: > ++ System.out.println("it Worked!"); // TODO: Remove before commit. Should be removed! > ++ private static void cleanPending() { > ++ if (temp == null) temp = new HashSet(); > ++ temp.clear(); > ++ for (String s : pending) { > ++ if (s != null) { > ++ String tmp = s.split("-", 2)[0].toLowerCase(); > ++ if (!asked.contains(s)) temp.add(tmp); > ++ } > ++ } > ++ pending.clear(); > ++ pending.addAll(temp); > ++ } > ++ temp is only used in this function. It should be in local scope only. > ++ private static boolean haveMissing() { > ++ switch (missingChars.size()) { > ++ case 0: > ++ return false; > ++ } > ++ return true; > ++ } > ++ > ++ private static boolean havePending() { > ++ synchronized (asked) { > ++ pending.removeAll(asked); > ++ } You are locking on the instance that will be read (asked), but not on the instance what will be written to... > + > ++ // Must always be set back to false after changing. > ++ public static boolean recheckFont = false; > ++ I can't see anything using recheckFont ... > +@@ -83,6 +102,7 @@ > + char data[], int offset, int length, > + int ix, int iy) > + { > ++ Font f = GlyphChecker.dupeFont(sg2d.getFont()); > + FontInfo info = sg2d.getFontInfo(); > + float x, y; > + if (info.pixelHeight > OutlineTextRenderer.THRESHHOLD) { > +@@ -101,6 +121,20 @@ > + } > + GlyphList gl = GlyphList.getInstance(); > + if (gl.setFromChars(info, data, offset, length, x, y)) { > ++ if (GlyphChecker.doAll()) { > ++ gl.dispose(); > ++ GlyphChecker.getSunGraphicsEnvironment().recheckForNewFonts(); > ++ try { > ++ sg2d.setFont(f); // need to reset font and search since it will change to default. > ++ Font2DHandle h = FontManager.findFont2D(f.getName(), f.getStyle(), FontManager.LOGICAL_FALLBACK).handle; > ++ FontManager.setFont2D(f, h); > ++ } catch (NullPointerException npe) { > ++ // Do nothing proceed like nothing happened. > ++ } > ++ info = sg2d.getFontInfo(); > ++ gl = GlyphList.getInstance(); > ++ gl.setFromChars(info, data, offset, length, x, y); > ++ } > + drawGlyphList(sg2d, gl); > + gl.dispose(); This block looks very similar to the one above. Are the identical? If so, they should be in a function. > + } else { > +diff -r 9d90acd9f99f src/solaris/native/sun/awt/fontpath.c > +--- openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Wed Feb 16 09:39:35 2011 -0500 > ++++ openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Wed Mar 02 09:24:59 2011 -0500 > +@@ -517,11 +517,11 @@ > + } > + > + JNIEXPORT jstring JNICALL Java_sun_font_FontManager_getFontPath > +-(JNIEnv *env, jclass obj, jboolean noType1) { > ++(JNIEnv *env, jclass obj, jboolean noType1, jboolean recheck) { We should find some other way to recheck (whatever it is doing). Changing a public api, even for a sun.* class is a no-no. Deepak From dbhole at redhat.com Thu Apr 14 12:49:24 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 15:49:24 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <1416518579.313636.1302806820656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110414132202.GA32038@redhat.com> <1416518579.313636.1302806820656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414194924.GI9899@redhat.com> * Denis Lila [2011-04-14 14:47]: > > I mentioned it in the comments, it is so that > > PluginAppletViewer.waitTillTimeout() could remain private (the above > > is in a > > separate class). I intend to re-factor a lot of that code (already > > started > > working on it yesterday) that will address it there. In the mean time, > > I > > saw no harm in duplicating a few lines of code. > > Will you make the factory a static inner class in PAV? I think having > two separate classes in the same file is pretty ugly. > Yep. > > > > - } catch (InterruptedException ie) { > > > > - // just wait > > > > + int maxTimeToSleep = APPLET_TIMEOUT; > > > > + synchronized(status) { > > > > + while > > > > (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && > > > > + maxTimeToSleep > 0) { > > > > + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); > > > > > > Is status guaranteed to contain a mapping for identifier? > > > > > > > Yes, it is. > > I never liked the existence of this "status" map. We need "applets" > because we have static methods that have to have access to all PAV objects. > status, on the other hand is just a way to associate some data > with each PAV instance, but that's exactly what members are for. > I think statuses should eventually become members, and updateStatus should > stop being static (though not necessarily in this changeset). > Not sure what you mean.. status maps are used by static methods as well. They are used to handle cases where a window is closed during initialization (i.e. where a PAV instance for that applet may not exist yet). > One more thing: I think it might be better to introduce 2-3 > lock objects just for use with .wait and .notify. I don't think > it's a very good idea to lock on status and applets because we > don't know what kind of internal synchronization they use. Regardless of what the internal synchronization is, the worst case I can think of is unnecessary wake ups on notify (internal or in PAV), which I don't think are serious enough to be creating multiple lock only objects for. Cheers, Deepak > It's generally safer to lock on private objects that only we > have access to (and it also might reduce contention). > > Other than these minor things, I can't find anything wrong > with the patch (that is, your new patch, with nano time). > > Regards, > Denis. > > ----- Original Message ----- > > * Dr Andrew John Hughes [2011-04-14 07:41]: > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > Hi, > > > > > > > > > > Andrew mentioned in one of the previous threads that the current > > > > > plugin > > > > > code waits in an inefficient manner. It wakes up periodically to > > > > > check for conditions, and goes back to sleep, and keeps doing > > > > > that > > > > > cyclically. > > > > > > > > > > The attached patch uses a new function that uses object.wait for > > > > > the object of interest. > > From dbhole at redhat.com Thu Apr 14 12:50:29 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 15:50:29 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <4DA7443B.4070307@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <4DA70B10.4030801@redhat.com> <20110414150415.GB9899@redhat.com> <20110414182908.GF9899@redhat.com> <4DA7443B.4070307@redhat.com> Message-ID: <20110414195029.GJ9899@redhat.com> * Omair Majid [2011-04-14 15:00]: > On 04/14/2011 02:29 PM, Deepak Bhole wrote: > >* Deepak Bhole [2011-04-14 11:05]: > >>> * Omair Majid [2011-04-14 10:56]: > >>>> > On 04/14/2011 01:56 AM, Deepak Bhole wrote: > > > >>> > >>> Ah, neat. I didn't know that. I will make the change. > >>> > >New patch attached. It uses nanoTime(). > > > > Just one concern, noted below. > > >@@ -142,14 +140,19 @@ > > initEventQueue(panel); > > > > // Wait for panel to come alive > >- int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive > >- int wait = 0; > >- while (!panel.isAlive()&& wait< maxWait) { > >- try { > >- Thread.sleep(50); > >- wait += 50; > >- } catch (InterruptedException ie) { > >- // just wait > >+ // Wait implemented the long way so that > >+ // PluginAppletViewer.waitTillTimeout() needn't be exposed. > >+ long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > >+ > >+ synchronized(panel) { > >+ while (!panel.isAlive()&& maxTimeToSleep> 0) { > >+ long sleepStart = System.nanoTime(); > >+ > >+ try { > >+ panel.wait(maxTimeToSleep); > >+ } catch (InterruptedException e) {} // Just loop back > >+ > >+ maxTimeToSleep -= System.nanoTime() - sleepStart; > > maxTimeToSleep is in ns, but wait expects ms. waitTillTimeout() > converts the timeout in ns to ms before passing it to wait(). I > think we should do something similar here. > Ah, good catch. I will add a conversion there before committing. > Everything else looks fine to me. > Thanks! Deepak > Cheers, > Omair From dlila at redhat.com Thu Apr 14 13:03:11 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 16:03:11 -0400 (EDT) Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414194924.GI9899@redhat.com> Message-ID: <1201349727.320015.1302811391429.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > (i.e. where a PAV instance for that applet may not exist yet). I see. I'm ok with this patch then (after the nano/milli problem Omair spotted is fixed). Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-14 14:47]: > > > I mentioned it in the comments, it is so that > > > PluginAppletViewer.waitTillTimeout() could remain private (the > > > above > > > is in a > > > separate class). I intend to re-factor a lot of that code (already > > > started > > > working on it yesterday) that will address it there. In the mean > > > time, > > > I > > > saw no harm in duplicating a few lines of code. > > > > Will you make the factory a static inner class in PAV? I think > > having > > two separate classes in the same file is pretty ugly. > > > > Yep. > > > > > > - } catch (InterruptedException ie) { > > > > > - // just wait > > > > > + int maxTimeToSleep = APPLET_TIMEOUT; > > > > > + synchronized(status) { > > > > > + while > > > > > (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) > > > > > && > > > > > + maxTimeToSleep > 0) { > > > > > + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); > > > > > > > > Is status guaranteed to contain a mapping for identifier? > > > > > > > > > > Yes, it is. > > > > I never liked the existence of this "status" map. We need "applets" > > because we have static methods that have to have access to all PAV > > objects. > > status, on the other hand is just a way to associate some data > > with each PAV instance, but that's exactly what members are for. > > I think statuses should eventually become members, and updateStatus > > should > > stop being static (though not necessarily in this changeset). > > > > Not sure what you mean.. status maps are used by static methods as > well. > They are used to handle cases where a window is closed during > initialization > > > One more thing: I think it might be better to introduce 2-3 > > lock objects just for use with .wait and .notify. I don't think > > it's a very good idea to lock on status and applets because we > > don't know what kind of internal synchronization they use. > > Regardless of what the internal synchronization is, the worst case I > can > think of is unnecessary wake ups on notify (internal or in PAV), which > I > don't think are serious enough to be creating multiple lock only > objects > for. > > Cheers, > Deepak > > > It's generally safer to lock on private objects that only we > > have access to (and it also might reduce contention). > > > > Other than these minor things, I can't find anything wrong > > with the patch (that is, your new patch, with nano time). > > > > Regards, > > Denis. > > > > ----- Original Message ----- > > > * Dr Andrew John Hughes [2011-04-14 07:41]: > > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > > Hi, > > > > > > > > > > > > Andrew mentioned in one of the previous threads that the > > > > > > current > > > > > > plugin > > > > > > code waits in an inefficient manner. It wakes up > > > > > > periodically to > > > > > > check for conditions, and goes back to sleep, and keeps > > > > > > doing > > > > > > that > > > > > > cyclically. > > > > > > > > > > > > The attached patch uses a new function that uses object.wait > > > > > > for > > > > > > the object of interest. > > > From dbhole at redhat.com Thu Apr 14 13:04:31 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 16:04:31 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <1201349727.320015.1302811391429.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110414194924.GI9899@redhat.com> <1201349727.320015.1302811391429.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414200431.GL9899@redhat.com> * Denis Lila [2011-04-14 16:03]: > > (i.e. where a PAV instance for that applet may not exist yet). > > I see. > > I'm ok with this patch then (after the nano/milli problem Omair > spotted is fixed). > Awesome, thanks for reviewing! Likewise for Omair, Andrew and Jiri -- thanks. Cheers, Deepak > Regards, > Denis. > > ----- Original Message ----- > > * Denis Lila [2011-04-14 14:47]: > > > > I mentioned it in the comments, it is so that > > > > PluginAppletViewer.waitTillTimeout() could remain private (the > > > > above > > > > is in a > > > > separate class). I intend to re-factor a lot of that code (already > > > > started > > > > working on it yesterday) that will address it there. In the mean > > > > time, > > > > I > > > > saw no harm in duplicating a few lines of code. > > > > > > Will you make the factory a static inner class in PAV? I think > > > having > > > two separate classes in the same file is pretty ugly. > > > > > > > Yep. > > > > > > > > - } catch (InterruptedException ie) { > > > > > > - // just wait > > > > > > + int maxTimeToSleep = APPLET_TIMEOUT; > > > > > > + synchronized(status) { > > > > > > + while > > > > > > (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) > > > > > > && > > > > > > + maxTimeToSleep > 0) { > > > > > > + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); > > > > > > > > > > Is status guaranteed to contain a mapping for identifier? > > > > > > > > > > > > > Yes, it is. > > > > > > I never liked the existence of this "status" map. We need "applets" > > > because we have static methods that have to have access to all PAV > > > objects. > > > status, on the other hand is just a way to associate some data > > > with each PAV instance, but that's exactly what members are for. > > > I think statuses should eventually become members, and updateStatus > > > should > > > stop being static (though not necessarily in this changeset). > > > > > > > Not sure what you mean.. status maps are used by static methods as > > well. > > They are used to handle cases where a window is closed during > > initialization > > > > > One more thing: I think it might be better to introduce 2-3 > > > lock objects just for use with .wait and .notify. I don't think > > > it's a very good idea to lock on status and applets because we > > > don't know what kind of internal synchronization they use. > > > > Regardless of what the internal synchronization is, the worst case I > > can > > think of is unnecessary wake ups on notify (internal or in PAV), which > > I > > don't think are serious enough to be creating multiple lock only > > objects > > for. > > > > Cheers, > > Deepak > > > > > It's generally safer to lock on private objects that only we > > > have access to (and it also might reduce contention). > > > > > > Other than these minor things, I can't find anything wrong > > > with the patch (that is, your new patch, with nano time). > > > > > > Regards, > > > Denis. > > > > > > ----- Original Message ----- > > > > * Dr Andrew John Hughes [2011-04-14 07:41]: > > > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > > > Hi, > > > > > > > > > > > > > > Andrew mentioned in one of the previous threads that the > > > > > > > current > > > > > > > plugin > > > > > > > code waits in an inefficient manner. It wakes up > > > > > > > periodically to > > > > > > > check for conditions, and goes back to sleep, and keeps > > > > > > > doing > > > > > > > that > > > > > > > cyclically. > > > > > > > > > > > > > > The attached patch uses a new function that uses object.wait > > > > > > > for > > > > > > > the object of interest. > > > > From dbhole at icedtea.classpath.org Thu Apr 14 13:26:18 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Thu, 14 Apr 2011 20:26:18 +0000 Subject: /hg/icedtea-web: Use Object.wait() instead of periodic wakes in ... Message-ID: changeset be45d9461f8d in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=be45d9461f8d author: Deepak Bhole date: Thu Apr 14 16:26:32 2011 -0400 Use Object.wait() instead of periodic wakes in PluginAppletViewer. diffstat: ChangeLog | 19 + plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 154 +++++++++----- 2 files changed, 117 insertions(+), 56 deletions(-) diffs (288 lines): diff -r 72de6393baca -r be45d9461f8d ChangeLog --- a/ChangeLog Thu Apr 14 12:24:46 2011 -0400 +++ b/ChangeLog Thu Apr 14 16:26:32 2011 -0400 @@ -1,3 +1,22 @@ +2011-04-13 Deepak Bhole + + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (createPanel): + use Object.wait() to wait, rather than pariodic sleep. + (APPLET_TIMEOUT): Updated to be in nanoseconds. + (framePanel): Synchronize put and notify threads waiting on the applets + map instance. + (appletStateChanged): Notify all threads waiting on the panel that just + changed state. + (handleMessage): Use the new waitTillTimeout function to wait, rather than + periodically waking up. Improved timeout error string sent back. + (updateStatus): Synchronize put and notify all threads waiting on status + map. + (waitForAppletInit): Use the new waitTillTimeout function to wait, rather + than periodically waking up. + (waitTillTimeout): New function. For a given non-null object, waits until + the specified timeout, or, if an interrupt was thrown during wait, returns + immediately. + 2011-04-14 Denis Lila * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java diff -r 72de6393baca -r be45d9461f8d plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 12:24:46 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 16:26:32 2011 -0400 @@ -91,12 +91,10 @@ import java.security.PrivilegedAction; import java.security.PrivilegedActionException; import java.security.PrivilegedExceptionAction; -import java.util.ArrayList; import java.util.Enumeration; import java.util.HashMap; import java.util.Hashtable; import java.util.Iterator; -import java.util.List; import java.util.Map; import java.util.Vector; import java.util.concurrent.ConcurrentHashMap; @@ -142,14 +140,19 @@ initEventQueue(panel); // Wait for panel to come alive - int maxWait = PluginAppletViewer.APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while (!panel.isAlive() && wait < maxWait) { - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + // Wait implemented the long way so that + // PluginAppletViewer.waitTillTimeout() needn't be exposed. + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT/1000000; // ns -> ms + + synchronized(panel) { + while (!panel.isAlive() && maxTimeToSleep > 0) { + long sleepStart = System.nanoTime(); + + try { + panel.wait(maxTimeToSleep); + } catch (InterruptedException e) {} // Just loop back + + maxTimeToSleep -= (System.nanoTime() - sleepStart)/1000000; // ns -> ms } } @@ -161,7 +164,7 @@ // Still null? if (a == null) { - streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); + streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError: " + "Initialization timed out"); return null; } @@ -277,7 +280,7 @@ private WindowListener windowEventListener = null; private AppletEventListener appletEventListener = null; - public static final int APPLET_TIMEOUT = 180000; + public static final long APPLET_TIMEOUT = 180000000000L; // 180s in ns private static final Object requestMutex = new Object(); private static long requestIdentityCounter = 0L; @@ -306,7 +309,11 @@ appletFrame.appletEventListener = new AppletEventListener(appletFrame, appletFrame); panel.addAppletListener(appletFrame.appletEventListener); - applets.put(identifier, appletFrame); + + synchronized(applets) { + applets.put(identifier, appletFrame); + applets.notifyAll(); + } PluginDebug.debug(panel, " framed"); } @@ -357,6 +364,10 @@ public void appletStateChanged(AppletEvent evt) { AppletPanel src = (AppletPanel) evt.getSource(); + synchronized (src) { + src.notifyAll(); + } + switch (evt.getID()) { case AppletPanel.APPLET_RESIZE: { if (src != null) { @@ -448,21 +459,16 @@ new StringReader(tag), new URL(documentBase)); - int maxWait = APPLET_TIMEOUT; // wait for applet to fully load - int wait = 0; - while (!applets.containsKey(identifier) && // Map is populated only by reFrame - (wait < maxWait)) { - - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + long maxTimeToSleep = APPLET_TIMEOUT; + synchronized(applets) { + while (!applets.containsKey(identifier) && + maxTimeToSleep > 0) { // Map is populated only by reFrame + maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); } } // If wait exceeded maxWait, we timed out. Throw an exception - if (wait >= maxWait) + if (maxTimeToSleep <= 0) throw new Exception("Applet initialization timeout"); // We should not try to destroy an applet during @@ -546,7 +552,11 @@ } // Else set to given status - status.put(identifier, newStatus); + + synchronized(status) { + status.put(identifier, newStatus); + status.notifyAll(); + } return prev; } @@ -599,25 +609,23 @@ } /** - * Function to block until applet initialization is complete + * Function to block until applet initialization is complete. + * + * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} * * @param panel the instance to wait for. */ public static void waitForAppletInit(NetxPanel panel) { - int waitTime = 0; + // Wait till initialization finishes + long maxTimeToSleep = APPLET_TIMEOUT; - // Wait till initialization finishes - while (panel.getApplet() == null && - panel.isAlive() && - waitTime < APPLET_TIMEOUT) { - try { - if (waitTime % 500 == 0) - PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); - - Thread.sleep(waitTime += 50); - } catch (InterruptedException ie) { - // just wait + synchronized(panel) { + while (panel.getApplet() == null && + panel.isAlive() && + maxTimeToSleep > 0) { + PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); } } @@ -628,14 +636,11 @@ if (message.startsWith("width")) { // Wait for panel to come alive - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && wait < maxWait) { - try { - Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait + long maxTimeToSleep = APPLET_TIMEOUT; + synchronized(status) { + while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && + maxTimeToSleep > 0) { + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); } } @@ -686,17 +691,21 @@ // FIXME: how do we determine what security context this // object should belong to? Object o; - - // Wait for panel to come alive - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive - int wait = 0; - while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { + + // First, wait for panel to instantiate + int waited = 0; + while (panel == null && waited < APPLET_TIMEOUT) { try { Thread.sleep(50); - wait += 50; - } catch (InterruptedException ie) { - // just wait - } + waited += 50; + } catch (InterruptedException ie) {} // discard, loop back + } + + // Next, wait for panel to come alive + long maxTimeToSleep = APPLET_TIMEOUT; + synchronized(panel) { + while (!panel.isAlive()) + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); } // Wait for the panel to initialize @@ -707,7 +716,7 @@ // Still null? if (panel.getApplet() == null) { - streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError " + "Initialization failed"); + streamhandler.write("instance " + identifier + " reference " + -1 + " fatalError: " + "Initialization timed out"); return; } @@ -2049,4 +2058,37 @@ // Draw the painted image g.drawImage(bufFrameImg, 0, 0, this); } + + /** + * Waits on a given object until timeout. + * + * This function assumes that the monitor lock has already been + * acquired by the caller. + * + * If the given object is null, this function returns immediately. + * + * @param obj The object to wait on + * @param timeout The maximum time to wait (nanoseconds) + * @return Approximate time spent sleeping (not guaranteed to be perfect) + */ + public static long waitTillTimeout(Object obj, long timeout) { + + // Can't wait on null. Return 0 indicating no wait happened. + if (obj == null) + return 0; + + // Record when we started sleeping + long sleepStart = 0L; + + // Convert timeout to ms since wait() takes ms + timeout = timeout >= 1000000 ? timeout/1000000 : 1; + + try { + sleepStart = System.nanoTime(); + obj.wait(timeout); + } catch (InterruptedException ie) {} // Discarded, time to return + + // Return the difference + return System.nanoTime() - sleepStart; + } } From ahughes at redhat.com Thu Apr 14 13:32:49 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 21:32:49 +0100 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414132202.GA32038@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <20110414114100.GC7262@rivendell.middle-earth.co.uk> <20110414132202.GA32038@redhat.com> Message-ID: <20110414203249.GI7262@rivendell.middle-earth.co.uk> On 09:22 Thu 14 Apr , Deepak Bhole wrote: > * Dr Andrew John Hughes [2011-04-14 07:41]: > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > * Deepak Bhole [2011-04-13 20:48]: > > > > Hi, > > > > > > > > Andrew mentioned in one of the previous threads that the current plugin > > > > code waits in an inefficient manner. It wakes up periodically to > > > > check for conditions, and goes back to sleep, and keeps doing that > > > > cyclically. > > > > > > > > The attached patch uses a new function that uses object.wait for > > > > the object of interest. > > > > > > > > > > Please see attached new patch. After leaving the office I realized that > > > there is a potential race condition in the old patch with locking the > > > object inside the wait function. Patch updated to do the locking > > > outside (and function comment updated to clearly state that). > > > > > > > Can you elaborate? If it's the same thread acquiring the lock in both > > cases, then it should be fine as they are re-entrant i.e. if the function > > attempts to lock it and the thread already holds the lock, it's a no-op. > > > > Before, the locking was inside the function, like so: > > while ! > waitTillTimeout(OBJ, timeout) > ... > ... > > > function ... waitTillTimeout(OBJ, timeout) { > > lock (OBJ) > OBJ.wait() > ... > } > > The problem was that condition on OBJ could've been false at check, but then > become true before waitTillTimeout() was called. This would result in an > incorrect wait until timeout. By moving the lock to before condition checking, > the code guarantees that waiting is done only if needed. > Oh yes, that wouldn't work. As I said, we need closures to do that all in one function :-( > As I wrote this, I realized that in order for the above to work, we would have > to lock the hashmap on update too since CHM's locking works differently and may > not lock the full table. I will post a separate patch in a bit with the change. > In the mean time, I have replied to other concerns below. > As I suggested in the previous mail, we should probably switch back to HMs and do all locking in the one place. > > > Cheers, > > > Deepak > > > > Comments inline. As Jiri said, a ChangeLog would be good too. > > > > Oops, sorry I should've mentioned, the ChangeLog is the same as before > (only the locking area changed). Here it is: > > 2011-04-13 Deepak Bhole > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (createPanel): > use Object.wait() to wait, rather than pariodic sleep. > (framePanel): Notify threads waiting on the applets map instance. > (appletStateChanged): Notify all threads waiting on the panel that just > changed state. > (handleMessage): Use the new waitTillTimeout function to wait, rather than > periodically waking up. > (updateStatus): Notify all threads waiting on status map. > (waitForAppletInit): Use the new waitTillTimeout function to wait, rather > than periodically waking up. > (waitTillTimeout): New function. For a given non-null object, waits until > the specified timeout, or, if an interrupt was thrown during wait, returns > immediately. Ok, didn't even read the previous e-mail when I saw it had been superceded. > > > > - // just wait > > > + // Wait implemented the long way so that > > > + // PluginAppletViewer.waitTillTimeout() needn't be exposed. > > > + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > > > + > > > + synchronized(panel) { > > > + while (!panel.isAlive() && maxTimeToSleep > 0) { > > > + long sleepStart = System.currentTimeMillis(); > > > + > > > + try { > > > + panel.wait(maxTimeToSleep); > > > + } catch (InterruptedException e) {} // Just loop back > > > + > > > + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); > > > > So this one matches src.wait() below? It's a little unclear due to the differing > > variable names. > > > > Is there a reason why this doesn't use waitTillTimeout? > > > > I mentioned it in the comments, it is so that > PluginAppletViewer.waitTillTimeout() could remain private (the above is in a > separate class). I intend to re-factor a lot of that code (already started > working on it yesterday) that will address it there. In the mean time, I > saw no harm in duplicating a few lines of code. Oh ok, wasn't clear from just the patch. > > > > } > > > } > > > > > > @@ -307,6 +310,10 @@ > > > panel.addAppletListener(appletFrame.appletEventListener); > > > > > > applets.put(identifier, appletFrame); > > > + > > > + synchronized(applets) { > > > + applets.notifyAll(); > > > + } > > > > > > PluginDebug.debug(panel, " framed"); > > > } > > > > This change is correct, but I'm a bit dubious about having one set of > > locks in the CHM for the put and our own lock on applets here. Maybe > > revert back to HashMaps and handle all locking in one place? > > > > We would then have to lock on all gets too. CHMs locking is more > efficient as it locks on only parts of the table. That is why I chose to > do locking only around code that needs it (the API requires wait and > notifyall to be calls from threads that own the monitor lock). CHMs aren't locked on gets either. They do have visibility guarantees. I'm a little worried about using the monitor of an object that we know does its own internal locking. If we're keeping CHMs, we should use our own locks in this class so we don't interfere. It doesn't matter what objects are used to synchronise on, just that we are consistent. > > > > - } catch (InterruptedException ie) { > > > - // just wait > > > + int maxTimeToSleep = APPLET_TIMEOUT; > > > + synchronized(status) { > > > + while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && > > > + maxTimeToSleep > 0) { > > > + maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); > > > > Is status guaranteed to contain a mapping for identifier? > > > > Yes, it is. > Ok was worried about the null which could be avoided by inverting the test. > > > } > > > } > > > > > > @@ -686,17 +693,21 @@ > > > // FIXME: how do we determine what security context this > > > // object should belong to? > > > Object o; > > > - > > > - // Wait for panel to come alive > > > - int maxWait = APPLET_TIMEOUT; // wait for panel to come alive > > > - int wait = 0; > > > - while ((panel == null) || (!panel.isAlive() && wait < maxWait)) { > > > + > > > + // First, wait for panel to instantiate > > > + int waited = 0; > > > + while (panel == null && waited < APPLET_TIMEOUT) { > > > try { > > > Thread.sleep(50); > > > - wait += 50; > > > - } catch (InterruptedException ie) { > > > - // just wait > > > - } > > > + waited += 50; > > > + } catch (InterruptedException ie) {} // discard, loop back > > > + } > > > + > > > + // Next, wait for panel to come alive > > > + long maxTimeToSleep = APPLET_TIMEOUT; > > > + synchronized(panel) { > > > + while (!panel.isAlive()) > > > + maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > > > > I presume panel is global to this instance? > > > > Maybe we should introduce something else to provide the conditional wait so you > > don't need this split between the null/sleep(50) loop and the initialising/notification loop. > > > > Yeah I wasn't too happy about having to keep the above. I thought about > introducing an additional lock for the object, but the truth is that the > sleep will happen for a very short time, if it ever does. Furthermore, > the above would get called only for liveconnect based applets, so it > didn't seem worth it. I can still do it if you prefer though. > I think it would be preferable to make the code clearer. It also removes the confusion with src.wait above and any possible conflict with CHM locking. Easier enough to use just an Object or the Lock/Condition objects provided by java.util.concurrent. > > > > Would have been nice to have closures for this. Then you could pass the condition > > to this method, and have the whole block handled here. :-) > > > > Only 20 more months if all goes well! :) > > Cheers, > Deepak > > > > } > > > > > > -- > > Andrew :) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and IcedTea > > http://www.gnu.org/software/classpath > > http://icedtea.classpath.org > > PGP Key: F5862A37 (https://keys.indymedia.org/) > > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at redhat.com Thu Apr 14 13:34:58 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Apr 2011 16:34:58 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest Message-ID: <4DA75A72.30008@redhat.com> Hi, The attached patch adds support in icedtea-web for finding other jars using the Class-Path entry in a jar's manifest file. An applet the demonstrates the bug is located at http://jung.sourceforge.net/applet/showlayouts2.html The logic of the patch is quite similar to the already-implemented case for jar indices: when a class cannot be found, we will download jars specified in the Class-Path and search there too. ChangeLog: 2011-04-14 Omair Majid * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: Add new private variable classpathsInManifest. (activateJars): When adding jar index, also add Class-Path entries from the Manifest.mf file in the jar. (loadClass): Search for jars specified in classpaths before looking for entries in jar index. (addNewJar): New method refactored from loadClass. Any thoughts or comments? Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: add-new-jars-from-classpath-01.patch Type: text/x-patch Size: 7016 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110414/f0a62151/add-new-jars-from-classpath-01.patch From ahughes at redhat.com Thu Apr 14 13:40:21 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 21:40:21 +0100 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414194924.GI9899@redhat.com> References: <20110414132202.GA32038@redhat.com> <1416518579.313636.1302806820656.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110414194924.GI9899@redhat.com> Message-ID: <20110414204021.GJ7262@rivendell.middle-earth.co.uk> On 15:49 Thu 14 Apr , Deepak Bhole wrote: snip... > > One more thing: I think it might be better to introduce 2-3 > > lock objects just for use with .wait and .notify. I don't think > > it's a very good idea to lock on status and applets because we > > don't know what kind of internal synchronization they use. > > Regardless of what the internal synchronization is, the worst case I can > think of is unnecessary wake ups on notify (internal or in PAV), which I > don't think are serious enough to be creating multiple lock only objects > for. > I mentioned this in my comments too but you seem to have committed anyway without waiting for my response. I think it's dangerous to be obtaining the monitor on the maps when we don't know what the internal synchronisation policy is and could conflict with internal locks. Much cleaner to have our own locking in the class. I'll post a patch. > Cheers, > Deepak > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From andrew at icedtea.classpath.org Thu Apr 14 13:41:37 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Thu, 14 Apr 2011 20:41:37 +0000 Subject: /hg/icedtea-web: Support Gentoo install location for JUnit 4. Message-ID: changeset b4db997469a2 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=b4db997469a2 author: Andrew John Hughes date: Thu Apr 14 21:41:32 2011 +0100 Support Gentoo install location for JUnit 4. 2010-04-11 Andrew John Hughes * configure.ac: Check Gentoo install location for JUnit 4. diffstat: ChangeLog | 5 +++++ configure.ac | 2 +- 2 files changed, 6 insertions(+), 1 deletions(-) diffs (24 lines): diff -r be45d9461f8d -r b4db997469a2 ChangeLog --- a/ChangeLog Thu Apr 14 16:26:32 2011 -0400 +++ b/ChangeLog Thu Apr 14 21:41:32 2011 +0100 @@ -1,3 +1,8 @@ +2010-04-11 Andrew John Hughes + + * configure.ac: + Check Gentoo install location for JUnit 4. + 2011-04-13 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (createPanel): diff -r be45d9461f8d -r b4db997469a2 configure.ac --- a/configure.ac Thu Apr 14 16:26:32 2011 -0400 +++ b/configure.ac Thu Apr 14 21:41:32 2011 +0100 @@ -86,7 +86,7 @@ IT_FIND_OPTIONAL_JAR([rhino], RHINO, [/usr/share/java/js.jar /usr/share/rhino-1.6/lib/js.jar]) IT_FIND_OPTIONAL_JAR([junit], JUNIT, - [/usr/share/java/junit4.jar]) + [/usr/share/java/junit4.jar /usr/share/junit-4/lib/junit.jar]) AC_CONFIG_FILES([jrunscript], [chmod u+x jrunscript]) AC_CONFIG_FILES([build.properties]) From dbhole at redhat.com Thu Apr 14 13:58:56 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 16:58:56 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414203249.GI7262@rivendell.middle-earth.co.uk> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <20110414114100.GC7262@rivendell.middle-earth.co.uk> <20110414132202.GA32038@redhat.com> <20110414203249.GI7262@rivendell.middle-earth.co.uk> Message-ID: <20110414205856.GM9899@redhat.com> * Dr Andrew John Hughes [2011-04-14 16:32]: > On 09:22 Thu 14 Apr , Deepak Bhole wrote: > > * Dr Andrew John Hughes [2011-04-14 07:41]: > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > Hi, > > > > > > > > > > Andrew mentioned in one of the previous threads that the current plugin > > > > > code waits in an inefficient manner. It wakes up periodically to > > > > > check for conditions, and goes back to sleep, and keeps doing that > > > > > cyclically. > > > > > > > > > > The attached patch uses a new function that uses object.wait for > > > > > the object of interest. > > > > > > > > > > > > > Please see attached new patch. After leaving the office I realized that > > > > there is a potential race condition in the old patch with locking the > > > > object inside the wait function. Patch updated to do the locking > > > > outside (and function comment updated to clearly state that). > > > > > > > > > > Can you elaborate? If it's the same thread acquiring the lock in both > > > cases, then it should be fine as they are re-entrant i.e. if the function > > > attempts to lock it and the thread already holds the lock, it's a no-op. > > > > > > > Before, the locking was inside the function, like so: > > > > while ! > > waitTillTimeout(OBJ, timeout) > > ... > > ... > > > > > > function ... waitTillTimeout(OBJ, timeout) { > > > > lock (OBJ) > > OBJ.wait() > > ... > > } > > > > The problem was that condition on OBJ could've been false at check, but then > > become true before waitTillTimeout() was called. This would result in an > > incorrect wait until timeout. By moving the lock to before condition checking, > > the code guarantees that waiting is done only if needed. > > > > Oh yes, that wouldn't work. As I said, we need closures to do that all in one function :-( > > > As I wrote this, I realized that in order for the above to work, we would have > > to lock the hashmap on update too since CHM's locking works differently and may > > not lock the full table. I will post a separate patch in a bit with the change. > > In the mean time, I have replied to other concerns below. > > > > As I suggested in the previous mail, we should probably switch back to HMs and do > all locking in the one place. > > > > > Cheers, > > > > Deepak > > > > > > Comments inline. As Jiri said, a ChangeLog would be good too. > > > > > > > Oops, sorry I should've mentioned, the ChangeLog is the same as before > > (only the locking area changed). Here it is: > > > > 2011-04-13 Deepak Bhole > > > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (createPanel): > > use Object.wait() to wait, rather than pariodic sleep. > > (framePanel): Notify threads waiting on the applets map instance. > > (appletStateChanged): Notify all threads waiting on the panel that just > > changed state. > > (handleMessage): Use the new waitTillTimeout function to wait, rather than > > periodically waking up. > > (updateStatus): Notify all threads waiting on status map. > > (waitForAppletInit): Use the new waitTillTimeout function to wait, rather > > than periodically waking up. > > (waitTillTimeout): New function. For a given non-null object, waits until > > the specified timeout, or, if an interrupt was thrown during wait, returns > > immediately. > > Ok, didn't even read the previous e-mail when I saw it had been superceded. > > > > > > > - // just wait > > > > + // Wait implemented the long way so that > > > > + // PluginAppletViewer.waitTillTimeout() needn't be exposed. > > > > + long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT; > > > > + > > > > + synchronized(panel) { > > > > + while (!panel.isAlive() && maxTimeToSleep > 0) { > > > > + long sleepStart = System.currentTimeMillis(); > > > > + > > > > + try { > > > > + panel.wait(maxTimeToSleep); > > > > + } catch (InterruptedException e) {} // Just loop back > > > > + > > > > + maxTimeToSleep -= (System.currentTimeMillis() - sleepStart); > > > > > > So this one matches src.wait() below? It's a little unclear due to the differing > > > variable names. > > > > > > Is there a reason why this doesn't use waitTillTimeout? > > > > > > > I mentioned it in the comments, it is so that > > PluginAppletViewer.waitTillTimeout() could remain private (the above is in a > > separate class). I intend to re-factor a lot of that code (already started > > working on it yesterday) that will address it there. In the mean time, I > > saw no harm in duplicating a few lines of code. > > Oh ok, wasn't clear from just the patch. > > > > > > > } > > > > } > > > > > > > > @@ -307,6 +310,10 @@ > > > > panel.addAppletListener(appletFrame.appletEventListener); > > > > > > > > applets.put(identifier, appletFrame); > > > > + > > > > + synchronized(applets) { > > > > + applets.notifyAll(); > > > > + } > > > > > > > > PluginDebug.debug(panel, " framed"); > > > > } > > > > > > This change is correct, but I'm a bit dubious about having one set of > > > locks in the CHM for the put and our own lock on applets here. Maybe > > > revert back to HashMaps and handle all locking in one place? > > > > > > > We would then have to lock on all gets too. CHMs locking is more > > efficient as it locks on only parts of the table. That is why I chose to > > do locking only around code that needs it (the API requires wait and > > notifyall to be calls from threads that own the monitor lock). > > CHMs aren't locked on gets either. They do have visibility guarantees. > > I'm a little worried about using the monitor of an object that we know does its > own internal locking. If we're keeping CHMs, we should use our own locks in this > class so we don't interfere. It doesn't matter what objects are used to synchronise > on, just that we are consistent. > Denis brought this up too. Maybe I am missing something -- even if CHM does its own locking, wouldn't the caller thread still own the monitor, thus making it a non-issue? We'd just be locking it earlier. If outside locking is a concern, that would make CHM very dangerous to use in any sort of multi-threaded environment that might lock it before an op. If the notifyAll is a concern -- all docs are very adamant about always doing wait in a loop as interrupts can be thrown any time, so in worst case the waiting thread would just wake up when it doesn't need to. Cheers, Deepak > > > > I think it would be preferable to make the code clearer. It also removes the confusion with > src.wait above and any possible conflict with CHM locking. Easier enough to use just an > Object or the Lock/Condition objects provided by java.util.concurrent. > > > > > > Would have been nice to have closures for this. Then you could pass the condition > > > to this method, and have the whole block handled here. :-) > > > > > > > Only 20 more months if all goes well! :) > > > > Cheers, > > Deepak > > > > > > } > > > > > > > > > -- > > > Andrew :) > > > > > > Free Java Software Engineer > > > Red Hat, Inc. (http://www.redhat.com) > > > > > > Support Free Java! > > > Contribute to GNU Classpath and IcedTea > > > http://www.gnu.org/software/classpath > > > http://icedtea.classpath.org > > > PGP Key: F5862A37 (https://keys.indymedia.org/) > > > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at redhat.com Thu Apr 14 14:30:57 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 14 Apr 2011 17:30:57 -0400 (EDT) Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414205856.GM9899@redhat.com> Message-ID: <224869783.321192.1302816657868.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Denis brought this up too. Maybe I am missing something -- even if CHM > does its own locking, wouldn't the caller thread still own the > monitor, > thus making it a non-issue? We'd just be locking it earlier. If > outside > locking is a concern, that would make CHM very dangerous to use in any > sort of multi-threaded environment that might lock it before an op. Whenever an object L does it's own locking, there's a deadlock possibility if we have code like this: synchronized(L) { synchronized(Other) { code; } } synchronized(Other) { L.anyMethod(); } And combing through code trying to find this pattern would be very annoying. For us, that's not a problem (yet). My concern when I brought this up was one of increased contention, but thinking about it more, it didn't make much sense, so I won't mention it. I really don't think we should go back to HMs though. If we did that we'd have to lock on every get. Regards, Denis. ----- Original Message ----- > * Dr Andrew John Hughes [2011-04-14 16:32]: > > On 09:22 Thu 14 Apr , Deepak Bhole wrote: > > > * Dr Andrew John Hughes [2011-04-14 07:41]: > > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > > Hi, > > > > > > > > > > > > Andrew mentioned in one of the previous threads that the > > > > > > current plugin ... From dbhole at redhat.com Thu Apr 14 14:40:35 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 14 Apr 2011 17:40:35 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <224869783.321192.1302816657868.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110414205856.GM9899@redhat.com> <224869783.321192.1302816657868.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414214035.GN9899@redhat.com> * Denis Lila [2011-04-14 17:30]: > > Denis brought this up too. Maybe I am missing something -- even if CHM > > does its own locking, wouldn't the caller thread still own the > > monitor, > > thus making it a non-issue? We'd just be locking it earlier. If > > outside > > locking is a concern, that would make CHM very dangerous to use in any > > sort of multi-threaded environment that might lock it before an op. > > Whenever an object L does it's own locking, there's a deadlock > possibility if we have code like this: > > synchronized(L) { > synchronized(Other) { > code; > } > } > > synchronized(Other) { > L.anyMethod(); > } > True, so lets say CHM = L, we have: synchronized(L) { L.method() } in our code, and then what can CHM have to make this an issue? synchronized(L) { synchronized(anything_else) { ... } } ? That would still not be an issue as the caller has already locked L. The caller (PAV) does no secondary locking. Sorry if I sound like I am trying to be difficult.. I am just trying to understand if there really is a problem here and if so, where. Cheers, Deepak > And combing through code trying to find this pattern would be very > annoying. > For us, that's not a problem (yet). My concern when I brought this up > was one of increased contention, but thinking about it more, it > didn't make much sense, so I won't mention it. > > I really don't think we should go back to HMs though. If we did that > we'd have to lock on every get. > > Regards, > Denis. > > ----- Original Message ----- > > * Dr Andrew John Hughes [2011-04-14 16:32]: > > > On 09:22 Thu 14 Apr , Deepak Bhole wrote: > > > > * Dr Andrew John Hughes [2011-04-14 07:41]: > > > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > > > Hi, > > > > > > > > > > > > > > Andrew mentioned in one of the previous threads that the > > > > > > > current plugin > ... From ahughes at redhat.com Thu Apr 14 15:22:46 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 23:22:46 +0100 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414205856.GM9899@redhat.com> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <20110414114100.GC7262@rivendell.middle-earth.co.uk> <20110414132202.GA32038@redhat.com> <20110414203249.GI7262@rivendell.middle-earth.co.uk> <20110414205856.GM9899@redhat.com> Message-ID: <20110414222246.GK7262@rivendell.middle-earth.co.uk> On 16:58 Thu 14 Apr , Deepak Bhole wrote: > * Dr Andrew John Hughes [2011-04-14 16:32]: > > > > CHMs aren't locked on gets either. They do have visibility guarantees. > > > > I'm a little worried about using the monitor of an object that we know does its > > own internal locking. If we're keeping CHMs, we should use our own locks in this > > class so we don't interfere. It doesn't matter what objects are used to synchronise > > on, just that we are consistent. > > > > Denis brought this up too. Yes, though I did first in my initial comments. > Maybe I am missing something -- even if CHM > does its own locking, wouldn't the caller thread still own the monitor, > thus making it a non-issue? We'd just be locking it earlier. If outside > locking is a concern, that would make CHM very dangerous to use in any > sort of multi-threaded environment that might lock it before an op. > Client-side locking is always dangerous unless you know the locking policy of the class. With Vector, Hashtable and Collections.synchronizedX it is documented that you lock on the collection. CHM explictly says that you can't lock the entire map. This is one of the reasons it provides putIfAbsent, etc. You can't do it externally. How do you know that another thread hasn't obtained the monitor due to a call to one of the CHM methods? I think it is safer and clearer to use separate locks as we aren't even using them to lock the collection contents but as signals. Even if you can guarantee that using the monitor of the collections won't cause issues, simplifying the code is generally a good idea to protect against mistakes. On that subject, this whole class probably needs a rewrite. > If the notifyAll is a concern -- all docs are very adamant about always > doing wait in a loop as interrupts can be thrown any time, so in worst > case the waiting thread would just wake up when it doesn't need to. > Yes, I know about this. That's standard rules on the use of condition queues. You have to allow for spurious wakeups. > Cheers, > Deepak > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 14 15:27:32 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 23:27:32 +0100 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <224869783.321192.1302816657868.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110414205856.GM9899@redhat.com> <224869783.321192.1302816657868.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110414222732.GL7262@rivendell.middle-earth.co.uk> On 17:30 Thu 14 Apr , Denis Lila wrote: snip... > > I really don't think we should go back to HMs though. If we did that > we'd have to lock on every get. > I don't particularly want to either, but I'm worried you're putting too much faith in CHMs. They do NOT lock for retrieval. They are only guaranteed to not show results mid-put and (the important benefit) provide "weakly consistent" iteration: 'The view's iterator is a "weakly consistent" iterator that will never throw ConcurrentModificationException, and guarantees to traverse elements as they existed upon construction of the iterator, and may (but is not guaranteed to) reflect any modifications subsequent to construction.' > Regards, > Denis. > > ----- Original Message ----- > > * Dr Andrew John Hughes [2011-04-14 16:32]: > > > On 09:22 Thu 14 Apr , Deepak Bhole wrote: > > > > * Dr Andrew John Hughes [2011-04-14 07:41]: > > > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > > > Hi, > > > > > > > > > > > > > > Andrew mentioned in one of the previous threads that the > > > > > > > current plugin > ... -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 14 15:38:20 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 23:38:20 +0100 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <4DA75A72.30008@redhat.com> References: <4DA75A72.30008@redhat.com> Message-ID: <20110414223819.GM7262@rivendell.middle-earth.co.uk> On 16:34 Thu 14 Apr , Omair Majid wrote: > Hi, > > The attached patch adds support in icedtea-web for finding other jars > using the Class-Path entry in a jar's manifest file. > > An applet the demonstrates the bug is located at > http://jung.sourceforge.net/applet/showlayouts2.html > > The logic of the patch is quite similar to the already-implemented case > for jar indices: when a class cannot be found, we will download jars > specified in the Class-Path and search there too. > > ChangeLog: > 2011-04-14 Omair Majid > > * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: Add new > private variable classpathsInManifest. > (activateJars): When adding jar index, also add Class-Path entries > from the Manifest.mf file in the jar. > (loadClass): Search for jars specified in classpaths before looking > for entries in jar index. > (addNewJar): New method refactored from loadClass. > > Any thoughts or comments? > > Cheers, > Omair Inline. > diff -r 24f034f372e4 netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Wed Apr 06 10:02:46 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Thu Apr 14 16:21:27 2011 -0400 > @@ -36,13 +36,16 @@ > import java.util.Collections; > import java.util.Enumeration; > import java.util.HashMap; > +import java.util.HashSet; > import java.util.LinkedList; > import java.util.List; > import java.util.Map; > +import java.util.Set; > import java.util.TreeSet; > import java.util.Vector; > import java.util.jar.JarEntry; > import java.util.jar.JarFile; > +import java.util.jar.Manifest; > > import net.sourceforge.jnlp.DownloadOptions; > import net.sourceforge.jnlp.ExtensionDesc; > @@ -138,6 +141,9 @@ > /** ArrayList containing jar indexes for various jars available to this classloader */ > private ArrayList jarIndexes = new ArrayList(); > > + /** Set of classpath strings declared in the manifest.mf files */ > + private Set classpathsInManfest = new HashSet(); > + > /** File entries in the jar files available to this classloader */ > private TreeSet jarEntries = new TreeSet(); > > @@ -765,8 +771,28 @@ > // there is currently no mechanism to cache files per > // instance.. so only index cached files > if (localFile != null) { > - JarIndex index = JarIndex.getJarIndex(new JarFile(localFile.getAbsolutePath()), > - null); > + JarFile jarFile = new JarFile(localFile.getAbsolutePath()); > + Manifest mf = jarFile.getManifest(); > + if (mf != null) { > + String classpath = mf.getMainAttributes().getValue("Class-Path"); > + String[] paths = classpath.split(" +"); > + for (String path : paths) { > + if (path.trim().length() == 0) { > + continue; > + } > + // we want to search for jars in the same subdir on the server > + // as this jar, so find out that subdirectory > + String dir = jar.getLocation().getPath(); > + int lastSlash = dir.lastIndexOf("/"); > + if (lastSlash != -1) { > + dir = dir.substring(0, lastSlash+1); > + } else { > + dir = ""; > + } > + classpathsInManfest.add(dir + path); > + } > + } > + JarIndex index = JarIndex.getJarIndex(jarFile, null); Classpaths are joined by '+'? > if (index != null) > jarIndexes.add(index); > } > @@ -1007,8 +1033,32 @@ > try { > result = loadClassExt(name); > } catch (ClassNotFoundException cnfe) { > + // Not found in external loader either > > - // Not found in external loader either. As a last resort, look in any available indexes > + // Look in 'Class-Path' as specified in the manifest file > + try { > + for (String classpath: classpathsInManfest) { > + JARDesc desc; > + try { > + URL jarUrl = new URL(file.getCodeBase(), classpath); > + desc = new JARDesc(jarUrl, null, null, false, true, false, true); > + } catch (MalformedURLException mfe) { > + throw new ClassNotFoundException(name); > + } > + try { > + addNewJar(desc); > + } catch (Exception e) { > + throw new ClassNotFoundException(name); > + } > + } > + > + result = loadClassExt(name); > + return result; > + } catch (ClassNotFoundException cnfe1) { > + // continue below > + } > + > + // As a last resort, look in any available indexes Exceptions are getting eaten. The CNFE should use the thrown exceptions as the initCause. I'm especially worried about just catching Exception; can we not be more specific? > > // Currently this loads jars directly from the site. We cannot cache it because this > // call is initiated from within the applet, which does not have disk read/write permissions > @@ -1026,33 +1076,11 @@ > } catch (MalformedURLException mfe) { > throw new ClassNotFoundException(name); > } > - > - available.add(desc); > - > - tracker.addResource(desc.getLocation(), > - desc.getVersion(), > - null, > - JNLPRuntime.getDefaultUpdatePolicy() > - ); > - > - URL remoteURL; > try { > - remoteURL = new URL(file.getCodeBase() + jarName); > - } catch (MalformedURLException mfe) { > - throw new ClassNotFoundException(name); > - } > - > - URL u; > - > - try { > - u = tracker.getCacheURL(remoteURL); > + addNewJar(desc); > } catch (Exception e) { > throw new ClassNotFoundException(name); > } > - > - if (u != null) > - addURL(u); > - What's happening here? > } > > // If it still fails, let it error out > @@ -1069,6 +1097,30 @@ > } > > /** > + * Adds a new JARDesc into this classloader. > + *

> + * This will add the JARDesc into the resourceTracker and block until it > + * is downloaded. > + * @param desc the JARDesc for the new jar > + */ > + private void addNewJar(JARDesc desc) { > + > + available.add(desc); > + > + tracker.addResource(desc.getLocation(), > + desc.getVersion(), > + null, > + JNLPRuntime.getDefaultUpdatePolicy() > + ); > + > + URL remoteURL = desc.getLocation(); > + > + URL u = tracker.getCacheURL(remoteURL); > + if (u != null) > + addURL(u); > + } > + > + /** > * Find the class in this loader or any of its extension loaders. > */ > protected Class findClass(String name) throws ClassNotFoundException { -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 14 15:42:53 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 23:42:53 +0100 Subject: [icedtea-web] RFC: Switch to explicit locks and condition queues in PAV Message-ID: <20110414224253.GN7262@rivendell.middle-earth.co.uk> This is the change I mentioned in the previous discussion. It replaces the use of CHM monitors with explicit locks and condition queues. It also simplifies (I hope) the panel lock case by using an explicit lock and condition queue rather than a mix of the panel object and sleep. I'm still a bit dubious about this class as a whole and this change needs heavy testing before inclusion. Can someone try this out? I have no idea how this stuff actually is run and tested sufficiently. Long term this class needs a ground-up redesign. We're patching holes here when this needs to go back to the drawing board IMHO. At present, I have no overview of what this class is doing and it's far too big. [Apologies in advance for a few whitespace issues in the patch. Clearly someone has previously regressed on our identation cleanup and emacs is auto-cleaning it up. I can easily drop these from the committed version using -w if required]. ChangeLog: 2010-04-14 Andrew John Hughes * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java, (PluginAppletPanelFactory.createPanel(PluginStreamHandler, int,long,int,int,URL,Hashtable)): Remove duplication of wait for panel.isAlive(). (PluginAppletViewer.panelLock): New lock used to track panel creation. (PluginAppletViewer.panelLive): Condition queue for panel creation. (PluginAppletViewer.appletsLock): New lock used to track additions to the applets map. (PluginAppletViewer.appletAdded): Condition queue for applet addition. (PluginAppletViewer.statusLock): New lock for status changes. (PluginAppletViewer.initComplete): Condition queue for initialisation completion. (PluginAppletViewer.framePanel(int,long,NetxPanel)): Replace synchronized block with use of appletsLock and notification on appletAdded condition queue. (AppletEventListener.appletStateChanged(AppletEvent)): Signal the panelLive condition queue that the panel is live. (PluginAppletViewer.handleMessage(int,int,String)): Wait on appletAdded condition queue for applet to be added to the applets map. (PluginAppletViewer.updateStatus(Int,PAV_INIT_STATUS)): Signal when a status change occurs using the initComplete condition queue. (PluginAppletViewer.waitForAppletInit(NetxPanel)): Wait on the panelLive condition queue until the panel is created. (PluginAppletViewer.handleMessage(int,String)): Wait on the initComplete condition queue until initialisation is complete. Wait on the panelLive signal until panel is created. (waitTillTimeout(ReentrantLock,Condition,long)): Convert to use ReentrantLock and Condition. Add assertion to check the lock is held. Avoid conversion between milliseconds and nanoseconds. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 -------------- next part -------------- diff -r b4db997469a2 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 21:41:32 2011 +0100 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 22:53:10 2011 +0100 @@ -97,8 +97,13 @@ import java.util.Iterator; import java.util.Map; import java.util.Vector; + import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.ConcurrentMap; +import java.util.concurrent.TimeUnit; + +import java.util.concurrent.locks.Condition; +import java.util.concurrent.locks.ReentrantLock; import javax.swing.SwingUtilities; @@ -139,25 +144,7 @@ // Start the applet initEventQueue(panel); - // Wait for panel to come alive - // Wait implemented the long way so that - // PluginAppletViewer.waitTillTimeout() needn't be exposed. - long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT/1000000; // ns -> ms - - synchronized(panel) { - while (!panel.isAlive() && maxTimeToSleep > 0) { - long sleepStart = System.nanoTime(); - - try { - panel.wait(maxTimeToSleep); - } catch (InterruptedException e) {} // Just loop back - - maxTimeToSleep -= (System.nanoTime() - sleepStart)/1000000; // ns -> ms - } - } - // Wait for the panel to initialize - // (happens in a separate thread) PluginAppletViewer.waitForAppletInit(panel); Applet a = panel.getApplet(); @@ -263,12 +250,17 @@ * The panel in which the applet is being displayed. */ private NetxPanel panel; - + static final ReentrantLock panelLock = new ReentrantLock(); + // CONDITION PREDICATE: panel.isAlive() + static final Condition panelLive = panelLock.newCondition(); private int identifier; // Instance identifier -> PluginAppletViewer object. private static ConcurrentMap applets = new ConcurrentHashMap(); + private static final ReentrantLock appletsLock = new ReentrantLock(); + // CONDITION PREDICATE: !applets.containsKey(identifier) + private static final Condition appletAdded = appletsLock.newCondition(); private static PluginStreamHandler streamhandler; @@ -276,6 +268,9 @@ private static ConcurrentMap status = new ConcurrentHashMap(); + private static final ReentrantLock statusLock = new ReentrantLock(); + // CONDITION PREDICATE: !status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) + private static final Condition initComplete = statusLock.newCondition(); private WindowListener windowEventListener = null; private AppletEventListener appletEventListener = null; @@ -309,11 +304,10 @@ appletFrame.appletEventListener = new AppletEventListener(appletFrame, appletFrame); panel.addAppletListener(appletFrame.appletEventListener); - - synchronized(applets) { - applets.put(identifier, appletFrame); - applets.notifyAll(); - } + appletsLock.lock(); + applets.put(identifier, appletFrame); + appletAdded.signalAll(); + appletsLock.unlock(); PluginDebug.debug(panel, " framed"); } @@ -364,9 +358,9 @@ public void appletStateChanged(AppletEvent evt) { AppletPanel src = (AppletPanel) evt.getSource(); - synchronized (src) { - src.notifyAll(); - } + panelLock.lock(); + panelLive.signalAll(); + panelLock.unlock(); switch (evt.getID()) { case AppletPanel.APPLET_RESIZE: { @@ -460,12 +454,17 @@ new URL(documentBase)); long maxTimeToSleep = APPLET_TIMEOUT; - synchronized(applets) { + appletsLock.lock(); + try { while (!applets.containsKey(identifier) && maxTimeToSleep > 0) { // Map is populated only by reFrame - maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); + maxTimeToSleep -= waitTillTimeout(appletsLock, appletAdded, + maxTimeToSleep); } } + finally { + appletsLock.unlock(); + } // If wait exceeded maxWait, we timed out. Throw an exception if (maxTimeToSleep <= 0) @@ -552,11 +551,11 @@ } // Else set to given status - - synchronized(status) { - status.put(identifier, newStatus); - status.notifyAll(); - } + + statusLock.lock(); + status.put(identifier, newStatus); + initComplete.signalAll(); + statusLock.unlock(); return prev; } @@ -610,7 +609,7 @@ /** * Function to block until applet initialization is complete. - * + * * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} * * @param panel the instance to wait for. @@ -620,14 +619,18 @@ // Wait till initialization finishes long maxTimeToSleep = APPLET_TIMEOUT; - synchronized(panel) { + panelLock.lock(); + try { while (panel.getApplet() == null && panel.isAlive() && maxTimeToSleep > 0) { PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); - maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); + maxTimeToSleep -= waitTillTimeout(panelLock, panelLive, maxTimeToSleep); } } + finally { + panelLock.unlock(); + } PluginDebug.debug("Applet panel ", panel, " initialized"); } @@ -637,12 +640,17 @@ // Wait for panel to come alive long maxTimeToSleep = APPLET_TIMEOUT; - synchronized(status) { + statusLock.lock(); + try { while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && maxTimeToSleep > 0) { - maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); + maxTimeToSleep -= waitTillTimeout(statusLock, initComplete, + maxTimeToSleep); } } + finally { + statusLock.unlock(); + } // 0 => width, 1=> width_value, 2 => height, 3=> height_value String[] dimMsg = message.split(" "); @@ -691,21 +699,18 @@ // FIXME: how do we determine what security context this // object should belong to? Object o; - + // First, wait for panel to instantiate - int waited = 0; - while (panel == null && waited < APPLET_TIMEOUT) { - try { - Thread.sleep(50); - waited += 50; - } catch (InterruptedException ie) {} // discard, loop back - } - // Next, wait for panel to come alive long maxTimeToSleep = APPLET_TIMEOUT; - synchronized(panel) { - while (!panel.isAlive()) - maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); + panelLock.lock(); + try { + while (panel == null || !panel.isAlive()) + maxTimeToSleep -= waitTillTimeout(panelLock, panelLive, + maxTimeToSleep); + } + finally { + panelLock.unlock(); } // Wait for the panel to initialize @@ -1370,7 +1375,7 @@ /** * Decodes the string (converts html escapes into proper characters) - * + * * @param toDecode The string to decode * @return The decoded string */ @@ -1385,7 +1390,7 @@ return toDecode; } - + /** * System parameters. */ @@ -1571,7 +1576,7 @@ public void run() { ClassLoader cl = p.applet.getClass().getClassLoader(); - // Since we want to deal with JNLPClassLoader, extract it if this + // Since we want to deal with JNLPClassLoader, extract it if this // is a codebase loader if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); @@ -2060,34 +2065,35 @@ } /** - * Waits on a given object until timeout. - * + * Waits on a given condition queue until timeout. + * * This function assumes that the monitor lock has already been * acquired by the caller. - * - * If the given object is null, this function returns immediately. - * - * @param obj The object to wait on + * + * If the given lock is null, this function returns immediately. + * + * @param lock the lock that must be held when this method is called. + * @param cond the condition queue on which to wait for notifications. * @param timeout The maximum time to wait (nanoseconds) * @return Approximate time spent sleeping (not guaranteed to be perfect) */ - public static long waitTillTimeout(Object obj, long timeout) { + public static long waitTillTimeout(ReentrantLock lock, Condition cond, + long timeout) { // Can't wait on null. Return 0 indicating no wait happened. - if (obj == null) + if (lock == null) return 0; - + + assert lock.isHeldByCurrentThread(); + // Record when we started sleeping long sleepStart = 0L; - // Convert timeout to ms since wait() takes ms - timeout = timeout >= 1000000 ? timeout/1000000 : 1; - try { sleepStart = System.nanoTime(); - obj.wait(timeout); + cond.await(timeout, TimeUnit.NANOSECONDS); } catch (InterruptedException ie) {} // Discarded, time to return - + // Return the difference return System.nanoTime() - sleepStart; } From ahughes at redhat.com Thu Apr 14 15:48:19 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 14 Apr 2011 23:48:19 +0100 Subject: DBus font installs [incomplete] In-Reply-To: <20110414193254.GH9899@redhat.com> References: <514115585.346074.1299088413470.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <154001230.347131.1299090878822.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <20110414193254.GH9899@redhat.com> Message-ID: <20110414224819.GO7262@rivendell.middle-earth.co.uk> On 15:32 Thu 14 Apr , Deepak Bhole wrote: > Please re-post this patch with proper docs for all of the functions and > comments on what the non-obvious lines of code are doing, especially > when they call external API. > Thanks for pinging this Deepak. Got lost in my mail box until now. > Comments on generic issues below: > > > * Andrew Su [2011-03-02 13:35]: > > Hello, > > > > This patch is an attempt at requesting users to install a font that will allow them to display the text being rendered if the glyph is missing. It is still a work in progress. > > > > Known issues: > > - Segmentation fault when rechecking for newly installed fonts to load. > > This is a showstopper. Nothing we add should make the JVM crash under > any circumstances. Agreed. But I don't think this means the code shouldn't go in so it can be worked on, as long as it is disabled by default. Having it available to all makes it easier to fix. I did ask Andrew to post his work so it wasn't lingering on his desk. I don't expect it to be perfect. > > > - If characters from different languages are being rendered one at a time it would constantly request user to install the languages not found. > > Can't we maintain a list and not ask back if the user said no once? > > > - May ask to install a non-standard language (unrecognised by packagekit). > > > > What will packagekit try to install if it is non-standard? > > > Attached: > > - addFontInstall.patch: This will add the patch and modify the Makefile accordingly. > > - GlyphChecker.c: Used to create libglyphchecker.so (which should be placed in the openjdk's lib directory. > > - GlyphChecker.h: Header for using jni. > > > > I used [on a x86_64 machine] > > > > gcc -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/include/ -I/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/include/linux/ -I/usr/include/dbus-1.0/ -I/usr/include/glib-2.0/ -I/usr/lib64/glib-2.0/include -shared -fPIC -g -O0 -Wall -lfontconfig -ldbus-glib-1 -o libglyphchecker.so GlyphChecker.c > > > > to build the library file. (Replace with where your libs are..) once compiled, place the .so into your jre's lib dir. > > ex: ${BUILD_DIR}/openjdk.build/j2sdk-image/jre/lib/amd64/ > > > > To test that it searches and installs fonts.. > > You can run it as follows: > > GlyphChecker.addMissing((char) 0x710); > > GlyphChecker.doAll(); // This should return true if you accepted to install > > This needs integrating into the Makefile before it can go in. > > Please let me know if you see any issues with it. > > > > ... > > #include > > #include > > #include > > > > FcChar8* getSuperSet(FcLangSet* fls) { > > // printf("Getting superset.\n"); > > > > Above should be removed. As should all other uncommented printfs I'd prefer we had something like #ifdef DEBUG round them as opposed to removing all of them altogether. snip... > > > + } else { > > +diff -r 9d90acd9f99f src/solaris/native/sun/awt/fontpath.c > > +--- openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Wed Feb 16 09:39:35 2011 -0500 > > ++++ openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Wed Mar 02 09:24:59 2011 -0500 > > +@@ -517,11 +517,11 @@ > > + } > > + > > + JNIEXPORT jstring JNICALL Java_sun_font_FontManager_getFontPath > > +-(JNIEnv *env, jclass obj, jboolean noType1) { > > ++(JNIEnv *env, jclass obj, jboolean noType1, jboolean recheck) { > > We should find some other way to recheck (whatever it is doing). > Changing a public api, even for a sun.* class is a no-no. > For sun.*, it's possible. I'd prefer it to some convoluted workaround. > Deepak -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at redhat.com Thu Apr 14 16:09:08 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 14 Apr 2011 19:09:08 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <20110414223819.GM7262@rivendell.middle-earth.co.uk> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> Message-ID: <4DA77E94.1000901@redhat.com> On 04/14/2011 06:38 PM, Dr Andrew John Hughes wrote: > On 16:34 Thu 14 Apr , Omair Majid wrote: >> > Hi, >> > >> > The attached patch adds support in icedtea-web for finding other jars >> > using the Class-Path entry in a jar's manifest file. >> > >> > An applet the demonstrates the bug is located at >> > http://jung.sourceforge.net/applet/showlayouts2.html >> > >> > The logic of the patch is quite similar to the already-implemented case >> > for jar indices: when a class cannot be found, we will download jars >> > specified in the Class-Path and search there too. >> > >> > ChangeLog: >> > 2011-04-14 Omair Majid >> > >> > * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: Add new >> > private variable classpathsInManifest. >> > (activateJars): When adding jar index, also add Class-Path entries >> > from the Manifest.mf file in the jar. >> > (loadClass): Search for jars specified in classpaths before looking >> > for entries in jar index. >> > (addNewJar): New method refactored from loadClass. >> > >> > Any thoughts or comments? >> > >> > Cheers, >> > Omair > Inline. Thanks for the comments! >> > @@ -765,8 +771,28 @@ >> > // there is currently no mechanism to cache files per >> > // instance.. so only index cached files >> > if (localFile != null) { >> > - JarIndex index = JarIndex.getJarIndex(new JarFile(localFile.getAbsolutePath()), >> > - null); >> > + JarFile jarFile = new JarFile(localFile.getAbsolutePath()); >> > + Manifest mf = jarFile.getManifest(); >> > + if (mf != null) { >> > + String classpath = mf.getMainAttributes().getValue("Class-Path"); >> > + String[] paths = classpath.split(" +"); >> > + for (String path : paths) { >> > + if (path.trim().length() == 0) { >> > + continue; >> > + } >> > + // we want to search for jars in the same subdir on the server >> > + // as this jar, so find out that subdirectory >> > + String dir = jar.getLocation().getPath(); >> > + int lastSlash = dir.lastIndexOf("/"); >> > + if (lastSlash != -1) { >> > + dir = dir.substring(0, lastSlash+1); >> > + } else { >> > + dir = ""; >> > + } >> > + classpathsInManfest.add(dir + path); >> > + } >> > + } >> > + JarIndex index = JarIndex.getJarIndex(jarFile, null); > Classpaths are joined by '+'? > Each String in the Map is a classpath entry. The '+' is used to join the jar's directory with the actual jar name. As an example, consider the applet linked in the original email. The applet's jars are located at /applet/jar/*. The 'Class-Path' entries contain just the names of the jar - like foo.jar, bar.jar. The page (and hence the codebase) is /applet/. If we just joined the name of the jar with the codebase, the result is /applet/foo.jar, which is not the right path. This bit of code above joins the original jar's path to the Class-Path jars to create paths like /applet/jar/foo.jar and /applet/jar/bar.jar. On second thought, perhaps I should have documented this a little more. I thought my comment: // we want to search for jars in the same subdir on the server // as this jar, so find out that subdirectory was sufficient, but it may not be. >> > if (index != null) >> > jarIndexes.add(index); >> > } >> > @@ -1007,8 +1033,32 @@ >> > try { >> > result = loadClassExt(name); >> > } catch (ClassNotFoundException cnfe) { >> > + // Not found in external loader either >> > >> > - // Not found in external loader either. As a last resort, look in any available indexes >> > + // Look in 'Class-Path' as specified in the manifest file >> > + try { >> > + for (String classpath: classpathsInManfest) { >> > + JARDesc desc; >> > + try { >> > + URL jarUrl = new URL(file.getCodeBase(), classpath); >> > + desc = new JARDesc(jarUrl, null, null, false, true, false, true); >> > + } catch (MalformedURLException mfe) { >> > + throw new ClassNotFoundException(name); >> > + } >> > + try { >> > + addNewJar(desc); >> > + } catch (Exception e) { >> > + throw new ClassNotFoundException(name); >> > + } >> > + } >> > + >> > + result = loadClassExt(name); >> > + return result; >> > + } catch (ClassNotFoundException cnfe1) { >> > + // continue below >> > + } >> > + >> > + // As a last resort, look in any available indexes > Exceptions are getting eaten. The CNFE should use the thrown exceptions as the initCause. I'm especially > worried about just catching Exception; can we not be more specific? > I believe we want exceptions to be eaten here. This method, loadClass, can only throw ClassNotFoundExceptions. It has to search in a few locations and attempt a number of things before it realizes that a class can not be found. So the cause that it may throw (and that user code may see) is very likely to be meaningless anyway. As for catching Exception, you do have a point. I had left it the way it was originally (see the code below). I know that it can throw IllegalArgumentException if the Resource is not being tracked (which should not happen here). I suppose I can remove the catch block completely. What I want to do, essentially, is to try loading a class from the newly added jars, but map any Exceptions thrown to ClassNotFoundException, which I ignore. This ensures that nothing here stops the JNLPClassLoader. The JNLPClassLoader can then try other methods for loading the class. >> > >> > // Currently this loads jars directly from the site. We cannot cache it because this >> > // call is initiated from within the applet, which does not have disk read/write permissions >> > @@ -1026,33 +1076,11 @@ >> > } catch (MalformedURLException mfe) { >> > throw new ClassNotFoundException(name); >> > } >> > - >> > - available.add(desc); >> > - >> > - tracker.addResource(desc.getLocation(), >> > - desc.getVersion(), >> > - null, >> > - JNLPRuntime.getDefaultUpdatePolicy() >> > - ); >> > - >> > - URL remoteURL; >> > try { >> > - remoteURL = new URL(file.getCodeBase() + jarName); >> > - } catch (MalformedURLException mfe) { >> > - throw new ClassNotFoundException(name); >> > - } >> > - >> > - URL u; >> > - >> > - try { >> > - u = tracker.getCacheURL(remoteURL); >> > + addNewJar(desc); >> > } catch (Exception e) { >> > throw new ClassNotFoundException(name); >> > } >> > - >> > - if (u != null) >> > - addURL(u); >> > - > What's happening here? No functional changes. This bit of code here would have been duplicated in the part that downloads jars from the Class-Path. To eliminate the duplication, I moved it to the new method addNewJar and made both places call that. Thanks, Omair From bugzilla-daemon at icedtea.classpath.org Thu Apr 14 17:02:35 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 15 Apr 2011 00:02:35 +0000 Subject: [Bug 687] BasicService.getCodeBase() returns null for IcedTea6 1.9.7 + OSGI In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 --- Comment #2 from Omair Majid 2011-04-15 00:02:35 --- Created an attachment (id=514) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=514) proposed patch The patch modifies how we try to find the JNLPClassLoader (from which we find the ApplicationInstance). We first search the Context ClassLoader (and it's parents) and then we search the ClassLoader for the classes on the stack (and their parents). The Launcher always sets the Context ClassLoader of the applications/applets it launches. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From ahughes at redhat.com Thu Apr 14 17:50:24 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 15 Apr 2011 01:50:24 +0100 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <4DA77E94.1000901@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> Message-ID: <20110415005024.GR7262@rivendell.middle-earth.co.uk> On 19:09 Thu 14 Apr , Omair Majid wrote: snip... > Each String in the Map is a classpath entry. The '+' is used to join the > jar's directory with the actual jar name. As an example, consider the > applet linked in the original email. The applet's jars are located at > /applet/jar/*. The 'Class-Path' entries contain just the names of the > jar - like foo.jar, bar.jar. The page (and hence the codebase) is > /applet/. If we just joined the name of the jar with the codebase, the > result is /applet/foo.jar, which is not the right path. This bit of code > above joins the original jar's path to the Class-Path jars to create > paths like /applet/jar/foo.jar and /applet/jar/bar.jar. > > On second thought, perhaps I should have documented this a little more. > I thought my comment: > // we want to search for jars in the same subdir on the server > // as this jar, so find out that subdirectory > was sufficient, but it may not be. > My main issue was that I wasn't familiar with this jar referencing syntax, but if you can make the documentation any clearer, that's always good. > >> > if (index != null) > >> > jarIndexes.add(index); > >> > } > >> > @@ -1007,8 +1033,32 @@ > >> > try { > >> > result = loadClassExt(name); > >> > } catch (ClassNotFoundException cnfe) { > >> > + // Not found in external loader either > >> > > >> > - // Not found in external loader either. As a last resort, look in any available indexes > >> > + // Look in 'Class-Path' as specified in the manifest file > >> > + try { > >> > + for (String classpath: classpathsInManfest) { > >> > + JARDesc desc; > >> > + try { > >> > + URL jarUrl = new URL(file.getCodeBase(), classpath); > >> > + desc = new JARDesc(jarUrl, null, null, false, true, false, true); > >> > + } catch (MalformedURLException mfe) { > >> > + throw new ClassNotFoundException(name); > >> > + } > >> > + try { > >> > + addNewJar(desc); > >> > + } catch (Exception e) { > >> > + throw new ClassNotFoundException(name); > >> > + } > >> > + } > >> > + > >> > + result = loadClassExt(name); > >> > + return result; > >> > + } catch (ClassNotFoundException cnfe1) { > >> > + // continue below > >> > + } > >> > + > >> > + // As a last resort, look in any available indexes > > Exceptions are getting eaten. The CNFE should use the thrown exceptions as the initCause. I'm especially > > worried about just catching Exception; can we not be more specific? > > > > I believe we want exceptions to be eaten here. This method, loadClass, > can only throw ClassNotFoundExceptions. It has to search in a few > locations and attempt a number of things before it realizes that a class > can not be found. So the cause that it may throw (and that user code may > see) is very likely to be meaningless anyway. > I have no problem with them throwing CNFEs but the cause should be there. If it's meaningless, it can be ignored, but if it's not there, we may lose essential debugging information. > As for catching Exception, you do have a point. I had left it the way it > was originally (see the code below). I know that it can throw > IllegalArgumentException if the Resource is not being tracked (which > should not happen here). I suppose I can remove the catch block completely. > Try it. > What I want to do, essentially, is to try loading a class from the newly > added jars, but map any Exceptions thrown to ClassNotFoundException, > which I ignore. This ensures that nothing here stops the > JNLPClassLoader. The JNLPClassLoader can then try other methods for > loading the class. > > >> > > >> > // Currently this loads jars directly from the site. We cannot cache it because this > >> > // call is initiated from within the applet, which does not have disk read/write permissions > >> > @@ -1026,33 +1076,11 @@ > >> > } catch (MalformedURLException mfe) { > >> > throw new ClassNotFoundException(name); > >> > } > >> > - > >> > - available.add(desc); > >> > - > >> > - tracker.addResource(desc.getLocation(), > >> > - desc.getVersion(), > >> > - null, > >> > - JNLPRuntime.getDefaultUpdatePolicy() > >> > - ); > >> > - > >> > - URL remoteURL; > >> > try { > >> > - remoteURL = new URL(file.getCodeBase() + jarName); > >> > - } catch (MalformedURLException mfe) { > >> > - throw new ClassNotFoundException(name); > >> > - } > >> > - > >> > - URL u; > >> > - > >> > - try { > >> > - u = tracker.getCacheURL(remoteURL); > >> > + addNewJar(desc); > >> > } catch (Exception e) { > >> > throw new ClassNotFoundException(name); > >> > } > >> > - > >> > - if (u != null) > >> > - addURL(u); > >> > - > > What's happening here? > > No functional changes. This bit of code here would have been duplicated > in the part that downloads jars from the Class-Path. To eliminate the > duplication, I moved it to the new method addNewJar and made both places > call that. > > Thanks, > Omair -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at redhat.com Fri Apr 15 05:35:33 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 15 Apr 2011 08:35:33 -0400 (EDT) Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414214035.GN9899@redhat.com> Message-ID: <468883710.348921.1302870933634.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > synchronized(L) { > L.method() > } In my example that was sync(Other) { L.foo(); } However, I pointed out that we don't have any cases like that in our code, so strictly speaking, there is no problem (yet). > That would still not be an issue as the caller has already locked L. > The caller (PAV) does no secondary locking. I agree that there's no correctness problem. AFAICS, the reasons for having separate locks would be 1. To protect against the introduction of future deadlocking code (that follows the pattern I mentioned). 2. Andrew mentioned that we're not using the present locking for safe access to the maps - we're just using it for wait/notify, and it's cleaner to have separate objects for this. > Sorry if I sound like I am trying to be difficult.. I am just trying > to understand if there really is a problem here and if so, where. I know :-D. Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-14 17:30]: > > > Denis brought this up too. Maybe I am missing something -- even if > > > CHM > > > does its own locking, wouldn't the caller thread still own the > > > monitor, > > > thus making it a non-issue? We'd just be locking it earlier. If > > > outside > > > locking is a concern, that would make CHM very dangerous to use in > > > any > > > sort of multi-threaded environment that might lock it before an > > > op. > > > > Whenever an object L does it's own locking, there's a deadlock > > possibility if we have code like this: > > > > synchronized(L) { > > synchronized(Other) { > > code; > > } > > } > > > > synchronized(Other) { > > L.anyMethod(); > > } > > > > True, so lets say CHM = L, we have: > > > in our code, and then what can CHM have to make this an issue? > > > ? > > > > Cheers, > Deepak > > > And combing through code trying to find this pattern would be very > > annoying. > > For us, that's not a problem (yet). My concern when I brought this > > up > > was one of increased contention, but thinking about it more, it > > didn't make much sense, so I won't mention it. > > > > I really don't think we should go back to HMs though. If we did that > > we'd have to lock on every get. > > > > Regards, > > Denis. > > > > ----- Original Message ----- > > > * Dr Andrew John Hughes [2011-04-14 16:32]: > > > > On 09:22 Thu 14 Apr , Deepak Bhole wrote: > > > > > * Dr Andrew John Hughes [2011-04-14 > > > > > 07:41]: > > > > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Andrew mentioned in one of the previous threads that the > > > > > > > > current plugin > > ... From dlila at redhat.com Fri Apr 15 06:05:35 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 15 Apr 2011 09:05:35 -0400 (EDT) Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414222732.GL7262@rivendell.middle-earth.co.uk> Message-ID: <430337975.349355.1302872735627.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > I don't particularly want to either, but I'm worried you're putting > too much faith in CHMs. They do NOT lock for retrieval. I know they don't lock on get. That's exactly why I wanted to use them. Why is it a problem that they don't? > They are only > guaranteed to not show results mid-put and (the important benefit) > provide "weakly consistent" iteration: > > 'The view's iterator is a "weakly consistent" iterator that will never > throw ConcurrentModificationException, and guarantees to traverse > elements as they existed upon construction of the iterator, and may > (but is not guaranteed to) reflect any modifications subsequent to > construction.' We're not using them for iteration, so I don't see how this is a problem. Regards, Denis. ----- Original Message ----- > On 17:30 Thu 14 Apr , Denis Lila wrote: > > snip... > > > > > I really don't think we should go back to HMs though. If we did that > > we'd have to lock on every get. > > > > > > > Regards, > > Denis. > > > > ----- Original Message ----- > > > * Dr Andrew John Hughes [2011-04-14 16:32]: > > > > On 09:22 Thu 14 Apr , Deepak Bhole wrote: > > > > > * Dr Andrew John Hughes [2011-04-14 > > > > > 07:41]: > > > > > > On 01:56 Thu 14 Apr , Deepak Bhole wrote: > > > > > > > * Deepak Bhole [2011-04-13 20:48]: > > > > > > > > Hi, > > > > > > > > > > > > > > > > Andrew mentioned in one of the previous threads that the > > > > > > > > current plugin > > ... > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ptisnovs at redhat.com Fri Apr 15 06:18:57 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 15 Apr 2011 15:18:57 +0200 Subject: PING: Reviewer needed - patch which fixes class SunToolkit for IcedTea6-1.8 and IcedTea6-1.9 In-Reply-To: <20110412123031.GE7262@rivendell.middle-earth.co.uk> References: <4DA3FF6D.3040101@redhat.com> <20110412123031.GE7262@rivendell.middle-earth.co.uk> Message-ID: <4DA845C1.7070207@redhat.com> Dr Andrew John Hughes wrote: > On 09:29 Tue 12 Apr , Pavel Tisnovsky wrote: > > That's why it's a good idea to post the specific patch being applied as > there will be changes when backporting. > > Here, there is a mistake; the NEWS item is being wrongly filed under Plugin > in both patches. It should be placed under 'Backports' as in HEAD and 1.10. > Hi Andrew, thank you for pointing this out. There are new diffs in an attachments. They were created today against recent versions of IcedTea6-1.8 and IcedTea6-1.9 respectively. ChangeLog entry: 2011-04-15 Pavel Tisnovsky * Makefile.am: Add new patch. * NEWS: Updated (added info about new fix). * patches/mark_sun_toolkit_privileged_code.patch: Patch which fixes the AccessControlException while working with Color class in a PropertyEditor Could you please review them? Thank you in advance Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: hg_diff_6-1.8.patch Type: text/x-patch Size: 1916 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110415/d6642035/hg_diff_6-1.8.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: hg_diff_6-1.9.patch Type: text/x-patch Size: 1844 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110415/d6642035/hg_diff_6-1.9.patch From ahughes at redhat.com Fri Apr 15 06:39:12 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 15 Apr 2011 14:39:12 +0100 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <430337975.349355.1302872735627.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110414222732.GL7262@rivendell.middle-earth.co.uk> <430337975.349355.1302872735627.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110415133912.GB29287@rivendell.middle-earth.co.uk> On 09:05 Fri 15 Apr , Denis Lila wrote: > > I don't particularly want to either, but I'm worried you're putting > > too much faith in CHMs. They do NOT lock for retrieval. > > I know they don't lock on get. That's exactly why I wanted to > use them. Why is it a problem that they don't? > I didn't say it was. I just wasn't sure you were aware of this. As you are obviously are, fine :-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Fri Apr 15 06:40:06 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 15 Apr 2011 14:40:06 +0100 Subject: PING: Reviewer needed - patch which fixes class SunToolkit for IcedTea6-1.8 and IcedTea6-1.9 In-Reply-To: <4DA845C1.7070207@redhat.com> References: <4DA3FF6D.3040101@redhat.com> <20110412123031.GE7262@rivendell.middle-earth.co.uk> <4DA845C1.7070207@redhat.com> Message-ID: <20110415134005.GC29287@rivendell.middle-earth.co.uk> On 15:18 Fri 15 Apr , Pavel Tisnovsky wrote: > Dr Andrew John Hughes wrote: > > On 09:29 Tue 12 Apr , Pavel Tisnovsky wrote: > > > > That's why it's a good idea to post the specific patch being applied as > > there will be changes when backporting. > > > > Here, there is a mistake; the NEWS item is being wrongly filed under Plugin > > in both patches. It should be placed under 'Backports' as in HEAD and 1.10. > > > Hi Andrew, > > thank you for pointing this out. There are new diffs in an attachments. > They were created today against recent versions of IcedTea6-1.8 and > IcedTea6-1.9 respectively. > > ChangeLog entry: > > 2011-04-15 Pavel Tisnovsky > > * Makefile.am: Add new patch. > * NEWS: Updated (added info about new fix). > * patches/mark_sun_toolkit_privileged_code.patch: > Patch which fixes the AccessControlException while > working with Color class in a PropertyEditor > > > Could you please review them? > > Thank you in advance > Pavel These look fine. Please commit them. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Fri Apr 15 07:00:02 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 15 Apr 2011 15:00:02 +0100 Subject: Fwd: Re: adding testng after removig of junit In-Reply-To: <4DA6E761.2010204@redhat.com> References: <4DA492E5.7050200@redhat.com> <20110414115826.GF7262@rivendell.middle-earth.co.uk> <4DA6E761.2010204@redhat.com> Message-ID: <20110415140001.GF29287@rivendell.middle-earth.co.uk> On 14:24 Thu 14 Apr , Jiri Vanek wrote: > On 04/14/2011 01:58 PM, Dr Andrew John Hughes wrote: > > On 19:59 Tue 12 Apr , Jiri Vanek wrote: > > > > snip... > > > > This is still the same arround:( Exactly. I really have too much on my plate at the moment to be wasting time in a circular argument which is going nowhere. It may be unintentional but the tone of your e-mail reads as very aggressive and accusatory. Your recent commit of this code also seemed purely designed to provoke anger. That's not an atmosphere I want to work in. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at redhat.com Fri Apr 15 07:09:20 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 15 Apr 2011 10:09:20 -0400 (EDT) Subject: [icedtea-web] RFC: Switch to explicit locks and condition queues in PAV In-Reply-To: <20110414224253.GN7262@rivendell.middle-earth.co.uk> Message-ID: <1587451938.355749.1302876560850.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > This is the change I mentioned in the previous discussion. It replaces > the use of CHM monitors with explicit locks and condition queues. It > also > simplifies (I hope) the panel lock case by using an explicit lock and > condition queue rather than a mix of the panel object and sleep. A few comments: > @@ -139,25 +144,7 @@ > // Start the applet > initEventQueue(panel); > > - // Wait for panel to come alive > - // Wait implemented the long way so that > - // PluginAppletViewer.waitTillTimeout() needn't be exposed. > - long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT/1000000; // ns -> ms > - > - synchronized(panel) { > - while (!panel.isAlive() && maxTimeToSleep > 0) { > - long sleepStart = System.nanoTime(); > - > - try { > - panel.wait(maxTimeToSleep); > - } catch (InterruptedException e) {} // Just loop back > - > - maxTimeToSleep -= (System.nanoTime() - sleepStart)/1000000; // ns -> ms > - } > - } > - > // Wait for the panel to initialize > - // (happens in a separate thread) > PluginAppletViewer.waitForAppletInit(panel); > > Applet a = panel.getApplet(); The code above wasn't replaced by anything. Was this intentional? > @@ -691,21 +699,18 @@ > // FIXME: how do we determine what security context this > // object should belong to? > Object o; > - > + > // First, wait for panel to instantiate > - int waited = 0; > - while (panel == null && waited < APPLET_TIMEOUT) { > - try { > - Thread.sleep(50); > - waited += 50; > - } catch (InterruptedException ie) {} // discard, loop back > - } > - > // Next, wait for panel to come alive > long maxTimeToSleep = APPLET_TIMEOUT; > - synchronized(panel) { > - while (!panel.isAlive()) > - maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > + panelLock.lock(); > + try { > + while (panel == null || !panel.isAlive()) > + maxTimeToSleep -= waitTillTimeout(panelLock, panelLive, > + maxTimeToSleep); > + } > + finally { > + panelLock.unlock(); > } > > // Wait for the panel to initialize I like this. I should mention that the new code is not equivalent to the old. Now we're using a static panelLock while before we were using a different lock for each panel (i.e. the panel itself). This doesn't seem to be a problem, but it's worth noting. > Long term this class needs a ground-up redesign. We're patching holes > here when this needs to go back to the drawing board IMHO. Won't that reintroduce bugs we've already fixed? ----- Original Message ----- > > I'm still a bit dubious about this class as a whole and this change > needs heavy testing before inclusion. Can someone try this out? I have > no idea how this stuff actually is run and tested sufficiently. > > > [Apologies in advance for a few whitespace issues in the patch. > Clearly > someone has previously regressed on our identation cleanup and emacs > is auto-cleaning it up. I can easily drop these from the committed > version using -w if required]. > > ChangeLog: > > 2010-04-14 Andrew John Hughes > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java, > (PluginAppletPanelFactory.createPanel(PluginStreamHandler, > int,long,int,int,URL,Hashtable)): Remove duplication of wait > for panel.isAlive(). > (PluginAppletViewer.panelLock): New lock used to track panel > creation. > (PluginAppletViewer.panelLive): Condition queue for panel creation. > (PluginAppletViewer.appletsLock): New lock used to track additions > to the applets map. > (PluginAppletViewer.appletAdded): Condition queue for applet addition. > (PluginAppletViewer.statusLock): New lock for status changes. > (PluginAppletViewer.initComplete): Condition queue for initialisation > completion. > (PluginAppletViewer.framePanel(int,long,NetxPanel)): > Replace synchronized block with use of appletsLock and notification > on appletAdded condition queue. > (AppletEventListener.appletStateChanged(AppletEvent)): Signal the > panelLive condition queue that the panel is live. > (PluginAppletViewer.handleMessage(int,int,String)): Wait on > appletAdded > condition queue for applet to be added to the applets map. > (PluginAppletViewer.updateStatus(Int,PAV_INIT_STATUS)): Signal when a > status change occurs using the initComplete condition queue. > (PluginAppletViewer.waitForAppletInit(NetxPanel)): Wait on the > panelLive > condition queue until the panel is created. > (PluginAppletViewer.handleMessage(int,String)): Wait on the > initComplete > condition queue until initialisation is complete. Wait on the > panelLive > signal until panel is created. > (waitTillTimeout(ReentrantLock,Condition,long)): Convert to use > ReentrantLock and Condition. Add assertion to check the lock is held. > Avoid conversion between milliseconds and nanoseconds. > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Fri Apr 15 07:14:06 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 15 Apr 2011 10:14:06 -0400 Subject: [icedtea-web] RFC: Patch to use wait() when waiting for conditions to become true In-Reply-To: <20110414222246.GK7262@rivendell.middle-earth.co.uk> References: <20110414004803.GA3875@redhat.com> <20110414055656.GA18391@redhat.com> <20110414114100.GC7262@rivendell.middle-earth.co.uk> <20110414132202.GA32038@redhat.com> <20110414203249.GI7262@rivendell.middle-earth.co.uk> <20110414205856.GM9899@redhat.com> <20110414222246.GK7262@rivendell.middle-earth.co.uk> Message-ID: <20110415141406.GA17759@redhat.com> * Dr Andrew John Hughes [2011-04-14 18:22]: > On 16:58 Thu 14 Apr , Deepak Bhole wrote: > > * Dr Andrew John Hughes [2011-04-14 16:32]: > > > > > > CHMs aren't locked on gets either. They do have visibility guarantees. > > > > > > I'm a little worried about using the monitor of an object that we know does its > > > own internal locking. If we're keeping CHMs, we should use our own locks in this > > > class so we don't interfere. It doesn't matter what objects are used to synchronise > > > on, just that we are consistent. > > > > > > > Denis brought this up too. > > Yes, though I did first in my initial comments. > > > Maybe I am missing something -- even if CHM > > does its own locking, wouldn't the caller thread still own the monitor, > > thus making it a non-issue? We'd just be locking it earlier. If outside > > locking is a concern, that would make CHM very dangerous to use in any > > sort of multi-threaded environment that might lock it before an op. > > > > Client-side locking is always dangerous unless you know the locking > policy of the class. With Vector, Hashtable and > Collections.synchronizedX it is documented that you lock on the > collection. CHM explictly says that you can't lock the entire map. > This is one of the reasons it provides putIfAbsent, etc. You can't do > it externally. How do you know that another thread hasn't obtained > the monitor due to a call to one of the CHM methods? > I think CHMs documentation is a bit misleading there. What that implies is that none of the operations exclusively lock (unlike Collections.synchronizedX which synchronizes each method around a single mutex). Locking on the object itself is still possible (and the generated bytecode seems to agree). > I think it is safer and clearer to use separate locks as we aren't > even using them to lock the collection contents but as signals. Even > if you can guarantee that using the monitor of the collections won't > cause issues, simplifying the code is generally a good idea to protect > against mistakes. On that subject, this whole class probably needs a > rewrite. > Fair enough. I won't argue from an aesthetics POV, especially since there is already a patch :) Checking it out now... Cheers, Deepak From ptisnovs at icedtea.classpath.org Fri Apr 15 07:15:20 2011 From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org) Date: Fri, 15 Apr 2011 14:15:20 +0000 Subject: /hg/release/icedtea6-1.8: Added patch that fixes AccessControlCo... Message-ID: changeset b0f229f276be in /hg/release/icedtea6-1.8 details: http://icedtea.classpath.org/hg/release/icedtea6-1.8?cmd=changeset;node=b0f229f276be author: ptisnovs date: Fri Apr 15 15:21:25 2011 +0200 Added patch that fixes AccessControlContext which was thrown while working with Color class in a PropertyEditor diffstat: ChangeLog | 8 ++++++++ Makefile.am | 3 ++- NEWS | 1 + patches/mark_sun_toolkit_privileged_code.patch | 11 +++++++++++ 4 files changed, 22 insertions(+), 1 deletions(-) diffs (55 lines): diff -r c4b749a83103 -r b0f229f276be ChangeLog --- a/ChangeLog Fri Mar 25 15:36:46 2011 -0400 +++ b/ChangeLog Fri Apr 15 15:21:25 2011 +0200 @@ -1,3 +1,11 @@ +2011-04-15 Pavel Tisnovsky + + * Makefile.am: Add new patch. + * NEWS: Updated (added info about new fix). + * patches/mark_sun_toolkit_privileged_code.patch: + Patch which fixes the AccessControlException while + working with Color class in a PropertyEditor + 2010-11-01 Deepak Bhole PR542: Plugin fails with NPE on diff -r c4b749a83103 -r b0f229f276be Makefile.am --- a/Makefile.am Fri Mar 25 15:36:46 2011 -0400 +++ b/Makefile.am Fri Apr 15 15:21:25 2011 +0200 @@ -377,7 +377,8 @@ patches/latent_jaxp_bug.patch \ patches/openjdk/6675802-securityExceptions-applets.patch \ patches/openjdk/6691503-malicious-applet-always-on-top.patch \ - patches/jtreg-LastErrorString.patch + patches/jtreg-LastErrorString.patch \ + patches/mark_sun_toolkit_privileged_code.patch if WITH_ALT_HSBUILD ICEDTEA_PATCHES += patches/hotspot/$(HSBUILD)/openjdk-6886353-ignore_deoptimizealot.patch \ diff -r c4b749a83103 -r b0f229f276be NEWS --- a/NEWS Fri Mar 25 15:36:46 2011 -0400 +++ b/NEWS Fri Apr 15 15:21:25 2011 +0200 @@ -14,6 +14,7 @@ - S6675802: Regression: heavyweight popups cause SecurityExceptions in applets - S6691503: Malicious applet can show always-on-top popup menu which has whole screen size - PR632: patches/security/20110215/6878713.patch breaks shark zero build + - Fixed AccessControlContext which was thrown while working with Color class in a PropertyEditor * Plugin - PR542: Plugin fails with NPE on http://www.openprocessing.org/visuals/iframe.php?visualID=2615 diff -r c4b749a83103 -r b0f229f276be patches/mark_sun_toolkit_privileged_code.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/mark_sun_toolkit_privileged_code.patch Fri Apr 15 15:21:25 2011 +0200 @@ -0,0 +1,12 @@ +--- openjdk/jdk/src/share/classes/sun/awt/SunToolkit.orig.java 2011-03-11 10:48:29.000000000 +0100 ++++ openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java 2011-03-11 11:24:33.000000000 +0100 +@@ -70,8 +70,7 @@ + + /* Load debug settings for native code */ + static { +- String nativeDebug = System.getProperty("sun.awt.nativedebug"); +- if ("true".equalsIgnoreCase(nativeDebug)) { ++ if (AccessController.doPrivileged(new GetBooleanAction("sun.awt.nativedebug"))) { + DebugSettings.init(); + } + }; From bugzilla-daemon at icedtea.classpath.org Fri Apr 15 07:30:30 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 15 Apr 2011 14:30:30 +0000 Subject: [Bug 690] Shark fails to JIT using hs20. In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=690 --- Comment #1 from Xerxes R?nby 2011-04-15 14:30:29 --- Created an attachment (id=515) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=515) hs20 patch against openjdk/hotspot pr690-shark-jit-hs20.patch This patch are made from cut out section of http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e863062e521d to fix this Shark JIT issue on hs20. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dbhole at redhat.com Fri Apr 15 07:31:08 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 15 Apr 2011 10:31:08 -0400 Subject: DBus font installs [incomplete] In-Reply-To: <20110414224819.GO7262@rivendell.middle-earth.co.uk> References: <514115585.346074.1299088413470.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <154001230.347131.1299090878822.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <20110414193254.GH9899@redhat.com> <20110414224819.GO7262@rivendell.middle-earth.co.uk> Message-ID: <20110415143108.GB17759@redhat.com> * Dr Andrew John Hughes [2011-04-14 18:48]: > On 15:32 Thu 14 Apr , Deepak Bhole wrote: > > > + } else { > > > +diff -r 9d90acd9f99f src/solaris/native/sun/awt/fontpath.c > > > +--- openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Wed Feb 16 09:39:35 2011 -0500 > > > ++++ openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Wed Mar 02 09:24:59 2011 -0500 > > > +@@ -517,11 +517,11 @@ > > > + } > > > + > > > + JNIEXPORT jstring JNICALL Java_sun_font_FontManager_getFontPath > > > +-(JNIEnv *env, jclass obj, jboolean noType1) { > > > ++(JNIEnv *env, jclass obj, jboolean noType1, jboolean recheck) { > > > > We should find some other way to recheck (whatever it is doing). > > Changing a public api, even for a sun.* class is a no-no. > > > > For sun.*, it's possible. I'd prefer it to some convoluted workaround. > Wouldn't that make OpenJDK less compatible with (admittedly bad) code that relies on sun.* API being a certain way? Deepak From dbhole at redhat.com Fri Apr 15 07:41:12 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 15 Apr 2011 10:41:12 -0400 Subject: [icedtea-web] RFC: Switch to explicit locks and condition queues in PAV In-Reply-To: <20110414224253.GN7262@rivendell.middle-earth.co.uk> References: <20110414224253.GN7262@rivendell.middle-earth.co.uk> Message-ID: <20110415144112.GC17759@redhat.com> * Dr Andrew John Hughes [2011-04-14 18:44]: > This is the change I mentioned in the previous discussion. It replaces > the use of CHM monitors with explicit locks and condition queues. It also > simplifies (I hope) the panel lock case by using an explicit lock and > condition queue rather than a mix of the panel object and sleep. > > I'm still a bit dubious about this class as a whole and this change > needs heavy testing before inclusion. Can someone try this out? I have > no idea how this stuff actually is run and tested sufficiently. > I don't know if we should be rewriting it. It took us a very long time to stabilize it (and as bad as the code is, it requires very little maintenance considering how much it does. Even the synch. issues Denis found have never manifested themselves afaik). This is one of the reasons I imported the class from the old plugin into the new one. That said, I strongly feel that it needs to be re-factored and made clean though, and I am looking into that now. Cheers, Deepak > Long term this class needs a ground-up redesign. We're patching holes > here when this needs to go back to the drawing board IMHO. At present, > I have no overview of what this class is doing and it's far too big. > > [Apologies in advance for a few whitespace issues in the patch. Clearly > someone has previously regressed on our identation cleanup and emacs > is auto-cleaning it up. I can easily drop these from the committed > version using -w if required]. > > ChangeLog: > > 2010-04-14 Andrew John Hughes > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java, > (PluginAppletPanelFactory.createPanel(PluginStreamHandler, > int,long,int,int,URL,Hashtable)): Remove duplication of wait > for panel.isAlive(). > (PluginAppletViewer.panelLock): New lock used to track panel > creation. > (PluginAppletViewer.panelLive): Condition queue for panel creation. > (PluginAppletViewer.appletsLock): New lock used to track additions > to the applets map. > (PluginAppletViewer.appletAdded): Condition queue for applet addition. > (PluginAppletViewer.statusLock): New lock for status changes. > (PluginAppletViewer.initComplete): Condition queue for initialisation > completion. > (PluginAppletViewer.framePanel(int,long,NetxPanel)): > Replace synchronized block with use of appletsLock and notification > on appletAdded condition queue. > (AppletEventListener.appletStateChanged(AppletEvent)): Signal the > panelLive condition queue that the panel is live. > (PluginAppletViewer.handleMessage(int,int,String)): Wait on appletAdded > condition queue for applet to be added to the applets map. > (PluginAppletViewer.updateStatus(Int,PAV_INIT_STATUS)): Signal when a > status change occurs using the initComplete condition queue. > (PluginAppletViewer.waitForAppletInit(NetxPanel)): Wait on the panelLive > condition queue until the panel is created. > (PluginAppletViewer.handleMessage(int,String)): Wait on the initComplete > condition queue until initialisation is complete. Wait on the panelLive > signal until panel is created. > (waitTillTimeout(ReentrantLock,Condition,long)): Convert to use > ReentrantLock and Condition. Add assertion to check the lock is held. > Avoid conversion between milliseconds and nanoseconds. > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 > diff -r b4db997469a2 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 21:41:32 2011 +0100 > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 22:53:10 2011 +0100 > @@ -97,8 +97,13 @@ > import java.util.Iterator; > import java.util.Map; > import java.util.Vector; > + > import java.util.concurrent.ConcurrentHashMap; > import java.util.concurrent.ConcurrentMap; > +import java.util.concurrent.TimeUnit; > + > +import java.util.concurrent.locks.Condition; > +import java.util.concurrent.locks.ReentrantLock; > > import javax.swing.SwingUtilities; > > @@ -139,25 +144,7 @@ > // Start the applet > initEventQueue(panel); > > - // Wait for panel to come alive > - // Wait implemented the long way so that > - // PluginAppletViewer.waitTillTimeout() needn't be exposed. > - long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT/1000000; // ns -> ms > - > - synchronized(panel) { > - while (!panel.isAlive() && maxTimeToSleep > 0) { > - long sleepStart = System.nanoTime(); > - > - try { > - panel.wait(maxTimeToSleep); > - } catch (InterruptedException e) {} // Just loop back > - > - maxTimeToSleep -= (System.nanoTime() - sleepStart)/1000000; // ns -> ms > - } > - } > - > // Wait for the panel to initialize > - // (happens in a separate thread) > PluginAppletViewer.waitForAppletInit(panel); > > Applet a = panel.getApplet(); > @@ -263,12 +250,17 @@ > * The panel in which the applet is being displayed. > */ > private NetxPanel panel; > - > + static final ReentrantLock panelLock = new ReentrantLock(); > + // CONDITION PREDICATE: panel.isAlive() > + static final Condition panelLive = panelLock.newCondition(); > private int identifier; > > // Instance identifier -> PluginAppletViewer object. > private static ConcurrentMap applets = > new ConcurrentHashMap(); > + private static final ReentrantLock appletsLock = new ReentrantLock(); > + // CONDITION PREDICATE: !applets.containsKey(identifier) > + private static final Condition appletAdded = appletsLock.newCondition(); > > private static PluginStreamHandler streamhandler; > > @@ -276,6 +268,9 @@ > > private static ConcurrentMap status = > new ConcurrentHashMap(); > + private static final ReentrantLock statusLock = new ReentrantLock(); > + // CONDITION PREDICATE: !status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) > + private static final Condition initComplete = statusLock.newCondition(); > > private WindowListener windowEventListener = null; > private AppletEventListener appletEventListener = null; > @@ -309,11 +304,10 @@ > appletFrame.appletEventListener = new AppletEventListener(appletFrame, appletFrame); > panel.addAppletListener(appletFrame.appletEventListener); > > - > - synchronized(applets) { > - applets.put(identifier, appletFrame); > - applets.notifyAll(); > - } > + appletsLock.lock(); > + applets.put(identifier, appletFrame); > + appletAdded.signalAll(); > + appletsLock.unlock(); > > PluginDebug.debug(panel, " framed"); > } > @@ -364,9 +358,9 @@ > public void appletStateChanged(AppletEvent evt) { > AppletPanel src = (AppletPanel) evt.getSource(); > > - synchronized (src) { > - src.notifyAll(); > - } > + panelLock.lock(); > + panelLive.signalAll(); > + panelLock.unlock(); > > switch (evt.getID()) { > case AppletPanel.APPLET_RESIZE: { > @@ -460,12 +454,17 @@ > new URL(documentBase)); > > long maxTimeToSleep = APPLET_TIMEOUT; > - synchronized(applets) { > + appletsLock.lock(); > + try { > while (!applets.containsKey(identifier) && > maxTimeToSleep > 0) { // Map is populated only by reFrame > - maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); > + maxTimeToSleep -= waitTillTimeout(appletsLock, appletAdded, > + maxTimeToSleep); > } > } > + finally { > + appletsLock.unlock(); > + } > > // If wait exceeded maxWait, we timed out. Throw an exception > if (maxTimeToSleep <= 0) > @@ -552,11 +551,11 @@ > } > > // Else set to given status > - > - synchronized(status) { > - status.put(identifier, newStatus); > - status.notifyAll(); > - } > + > + statusLock.lock(); > + status.put(identifier, newStatus); > + initComplete.signalAll(); > + statusLock.unlock(); > > return prev; > } > @@ -610,7 +609,7 @@ > > /** > * Function to block until applet initialization is complete. > - * > + * > * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} > * > * @param panel the instance to wait for. > @@ -620,14 +619,18 @@ > // Wait till initialization finishes > long maxTimeToSleep = APPLET_TIMEOUT; > > - synchronized(panel) { > + panelLock.lock(); > + try { > while (panel.getApplet() == null && > panel.isAlive() && > maxTimeToSleep > 0) { > PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); > - maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > + maxTimeToSleep -= waitTillTimeout(panelLock, panelLive, maxTimeToSleep); > } > } > + finally { > + panelLock.unlock(); > + } > > PluginDebug.debug("Applet panel ", panel, " initialized"); > } > @@ -637,12 +640,17 @@ > > // Wait for panel to come alive > long maxTimeToSleep = APPLET_TIMEOUT; > - synchronized(status) { > + statusLock.lock(); > + try { > while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && > maxTimeToSleep > 0) { > - maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); > + maxTimeToSleep -= waitTillTimeout(statusLock, initComplete, > + maxTimeToSleep); > } > } > + finally { > + statusLock.unlock(); > + } > > // 0 => width, 1=> width_value, 2 => height, 3=> height_value > String[] dimMsg = message.split(" "); > @@ -691,21 +699,18 @@ > // FIXME: how do we determine what security context this > // object should belong to? > Object o; > - > + > // First, wait for panel to instantiate > - int waited = 0; > - while (panel == null && waited < APPLET_TIMEOUT) { > - try { > - Thread.sleep(50); > - waited += 50; > - } catch (InterruptedException ie) {} // discard, loop back > - } > - > // Next, wait for panel to come alive > long maxTimeToSleep = APPLET_TIMEOUT; > - synchronized(panel) { > - while (!panel.isAlive()) > - maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > + panelLock.lock(); > + try { > + while (panel == null || !panel.isAlive()) > + maxTimeToSleep -= waitTillTimeout(panelLock, panelLive, > + maxTimeToSleep); > + } > + finally { > + panelLock.unlock(); > } > > // Wait for the panel to initialize > @@ -1370,7 +1375,7 @@ > > /** > * Decodes the string (converts html escapes into proper characters) > - * > + * > * @param toDecode The string to decode > * @return The decoded string > */ > @@ -1385,7 +1390,7 @@ > > return toDecode; > } > - > + > /** > * System parameters. > */ > @@ -1571,7 +1576,7 @@ > public void run() { > ClassLoader cl = p.applet.getClass().getClassLoader(); > > - // Since we want to deal with JNLPClassLoader, extract it if this > + // Since we want to deal with JNLPClassLoader, extract it if this > // is a codebase loader > if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) > cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); > @@ -2060,34 +2065,35 @@ > } > > /** > - * Waits on a given object until timeout. > - * > + * Waits on a given condition queue until timeout. > + * > * This function assumes that the monitor lock has already been > * acquired by the caller. > - * > - * If the given object is null, this function returns immediately. > - * > - * @param obj The object to wait on > + * > + * If the given lock is null, this function returns immediately. > + * > + * @param lock the lock that must be held when this method is called. > + * @param cond the condition queue on which to wait for notifications. > * @param timeout The maximum time to wait (nanoseconds) > * @return Approximate time spent sleeping (not guaranteed to be perfect) > */ > - public static long waitTillTimeout(Object obj, long timeout) { > + public static long waitTillTimeout(ReentrantLock lock, Condition cond, > + long timeout) { > > // Can't wait on null. Return 0 indicating no wait happened. > - if (obj == null) > + if (lock == null) > return 0; > - > + > + assert lock.isHeldByCurrentThread(); > + > // Record when we started sleeping > long sleepStart = 0L; > > - // Convert timeout to ms since wait() takes ms > - timeout = timeout >= 1000000 ? timeout/1000000 : 1; > - > try { > sleepStart = System.nanoTime(); > - obj.wait(timeout); > + cond.await(timeout, TimeUnit.NANOSECONDS); > } catch (InterruptedException ie) {} // Discarded, time to return > - > + > // Return the difference > return System.nanoTime() - sleepStart; > } From dbhole at redhat.com Fri Apr 15 07:43:40 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 15 Apr 2011 10:43:40 -0400 Subject: [icedtea-web] RFC: Switch to explicit locks and condition queues in PAV In-Reply-To: <20110414224253.GN7262@rivendell.middle-earth.co.uk> References: <20110414224253.GN7262@rivendell.middle-earth.co.uk> Message-ID: <20110415144340.GD17759@redhat.com> * Dr Andrew John Hughes [2011-04-14 18:44]: > This is the change I mentioned in the previous discussion. It replaces > the use of CHM monitors with explicit locks and condition queues. It also > simplifies (I hope) the panel lock case by using an explicit lock and > condition queue rather than a mix of the panel object and sleep. Er, forgot to talk about the patch... I see no issues. The concern Denis pointed out will cause spurious wake ups, but there are conditional checks around waitTillTimeout to ensure that the code goes back to sleep so it should be fine given the expected frequency of such events. Cheers, Deepak From ptisnovs at icedtea.classpath.org Fri Apr 15 07:44:57 2011 From: ptisnovs at icedtea.classpath.org (ptisnovs at icedtea.classpath.org) Date: Fri, 15 Apr 2011 14:44:57 +0000 Subject: /hg/release/icedtea6-1.9: Added patch that fixes AccessControlCo... Message-ID: changeset 2f549e3a4720 in /hg/release/icedtea6-1.9 details: http://icedtea.classpath.org/hg/release/icedtea6-1.9?cmd=changeset;node=2f549e3a4720 author: ptisnovs date: Fri Apr 15 15:51:17 2011 +0200 Added patch that fixes AccessControlContext which was thrown while working with Color class in a PropertyEditor diffstat: ChangeLog | 8 ++++++++ Makefile.am | 3 ++- NEWS | 1 + patches/mark_sun_toolkit_privileged_code.patch | 11 +++++++++++ 4 files changed, 22 insertions(+), 1 deletions(-) diffs (55 lines): diff -r 495cac553ab0 -r 2f549e3a4720 ChangeLog --- a/ChangeLog Tue Apr 12 15:47:27 2011 +0200 +++ b/ChangeLog Fri Apr 15 15:51:17 2011 +0200 @@ -1,3 +1,11 @@ +2011-04-15 Pavel Tisnovsky + + * Makefile.am: Add new patch. + * NEWS: Updated (added info about new fix). + * patches/mark_sun_toolkit_privileged_code.patch: + Patch which fixes the AccessControlException while + working with Color class in a PropertyEditor + 2011-04-12 Xerxes R??nby PR689: Shark fails to find LLVM 2.9 System headers during build diff -r 495cac553ab0 -r 2f549e3a4720 Makefile.am --- a/Makefile.am Tue Apr 12 15:47:27 2011 +0200 +++ b/Makefile.am Fri Apr 15 15:51:17 2011 +0200 @@ -341,7 +341,8 @@ patches/openjdk/6675802-securityExceptions-applets.patch \ patches/openjdk/6691503-malicious-applet-always-on-top.patch \ patches/jtreg-LastErrorString.patch \ - patches/shark-llvm-2.9.patch + patches/shark-llvm-2.9.patch \ + patches/mark_sun_toolkit_privileged_code.patch if WITH_ALT_HSBUILD ICEDTEA_PATCHES += \ diff -r 495cac553ab0 -r 2f549e3a4720 NEWS --- a/NEWS Tue Apr 12 15:47:27 2011 +0200 +++ b/NEWS Fri Apr 15 15:51:17 2011 +0200 @@ -14,6 +14,7 @@ - S6675802: Regression: heavyweight popups cause SecurityExceptions in applets - S6691503: Malicious applet can show always-on-top popup menu which has whole screen size - S6980392, PR642: simple correction in testcase, added missing bracket + - Fixed AccessControlContext which was thrown while working with Color class in a PropertyEditor * Plugin - PR542: Plugin fails with NPE on http://www.openprocessing.org/visuals/iframe.php?visualID=2615 * Shark diff -r 495cac553ab0 -r 2f549e3a4720 patches/mark_sun_toolkit_privileged_code.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/mark_sun_toolkit_privileged_code.patch Fri Apr 15 15:51:17 2011 +0200 @@ -0,0 +1,12 @@ +--- openjdk/jdk/src/share/classes/sun/awt/SunToolkit.orig.java 2011-03-11 10:48:29.000000000 +0100 ++++ openjdk/jdk/src/share/classes/sun/awt/SunToolkit.java 2011-03-11 11:24:33.000000000 +0100 +@@ -70,8 +70,7 @@ + + /* Load debug settings for native code */ + static { +- String nativeDebug = System.getProperty("sun.awt.nativedebug"); +- if ("true".equalsIgnoreCase(nativeDebug)) { ++ if (AccessController.doPrivileged(new GetBooleanAction("sun.awt.nativedebug"))) { + DebugSettings.init(); + } + }; From omajid at redhat.com Fri Apr 15 09:27:23 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Apr 2011 12:27:23 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <20110415005024.GR7262@rivendell.middle-earth.co.uk> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> Message-ID: <4DA871EB.2060907@redhat.com> Updated patch attached. On 04/14/2011 08:50 PM, Dr Andrew John Hughes wrote: > On 19:09 Thu 14 Apr , Omair Majid wrote: > > snip... > >> > Each String in the Map is a classpath entry. The '+' is used to join the >> > jar's directory with the actual jar name. As an example, consider the >> > applet linked in the original email. The applet's jars are located at >> > /applet/jar/*. The 'Class-Path' entries contain just the names of the >> > jar - like foo.jar, bar.jar. The page (and hence the codebase) is >> > /applet/. If we just joined the name of the jar with the codebase, the >> > result is /applet/foo.jar, which is not the right path. This bit of code >> > above joins the original jar's path to the Class-Path jars to create >> > paths like /applet/jar/foo.jar and /applet/jar/bar.jar. >> > >> > On second thought, perhaps I should have documented this a little more. >> > I thought my comment: >> > // we want to search for jars in the same subdir on the server >> > // as this jar, so find out that subdirectory >> > was sufficient, but it may not be. >> > > My main issue was that I wasn't familiar with this jar referencing syntax, but > if you can make the documentation any clearer, that's always good. > Do the comments in getClassPathsFromManifest help? >>>>> > >> > if (index != null) >>>>> > >> > jarIndexes.add(index); >>>>> > >> > } >>>>> > >> > @@ -1007,8 +1033,32 @@ >>>>> > >> > try { >>>>> > >> > result = loadClassExt(name); >>>>> > >> > } catch (ClassNotFoundException cnfe) { >>>>> > >> > + // Not found in external loader either >>>>> > >> > >>>>> > >> > - // Not found in external loader either. As a last resort, look in any available indexes >>>>> > >> > + // Look in 'Class-Path' as specified in the manifest file >>>>> > >> > + try { >>>>> > >> > + for (String classpath: classpathsInManfest) { >>>>> > >> > + JARDesc desc; >>>>> > >> > + try { >>>>> > >> > + URL jarUrl = new URL(file.getCodeBase(), classpath); >>>>> > >> > + desc = new JARDesc(jarUrl, null, null, false, true, false, true); >>>>> > >> > + } catch (MalformedURLException mfe) { >>>>> > >> > + throw new ClassNotFoundException(name); >>>>> > >> > + } >>>>> > >> > + try { >>>>> > >> > + addNewJar(desc); >>>>> > >> > + } catch (Exception e) { >>>>> > >> > + throw new ClassNotFoundException(name); >>>>> > >> > + } >>>>> > >> > + } >>>>> > >> > + >>>>> > >> > + result = loadClassExt(name); >>>>> > >> > + return result; >>>>> > >> > + } catch (ClassNotFoundException cnfe1) { >>>>> > >> > + // continue below >>>>> > >> > + } >>>>> > >> > + >>>>> > >> > + // As a last resort, look in any available indexes >>> > > Exceptions are getting eaten. The CNFE should use the thrown exceptions as the initCause. I'm especially >>> > > worried about just catching Exception; can we not be more specific? >>> > > >> > >> > I believe we want exceptions to be eaten here. This method, loadClass, >> > can only throw ClassNotFoundExceptions. It has to search in a few >> > locations and attempt a number of things before it realizes that a class >> > can not be found. So the cause that it may throw (and that user code may >> > see) is very likely to be meaningless anyway. >> > > I have no problem with them throwing CNFEs but the cause should be there. > If it's meaningless, it can be ignored, but if it's not there, we may lose > essential debugging information. > Ok, so I have modified the code to throw CNFE with causes. However, the code then catches (and logs) it. This allows the other methods of finding the jar to continue and the user code never gets to see the original CNFE. >> > As for catching Exception, you do have a point. I had left it the way it >> > was originally (see the code below). I know that it can throw >> > IllegalArgumentException if the Resource is not being tracked (which >> > should not happen here). I suppose I can remove the catch block completely. >> > > Try it. > Done. I havent seen any problems with the patch. However, I still think this is one of few cases where we should catch any exception and continue as if nothing has happened. Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: add-new-jars-from-classpath-02.patch Type: text/x-patch Size: 7549 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110415/3c1f834f/add-new-jars-from-classpath-02.patch From omajid at redhat.com Fri Apr 15 09:41:31 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Apr 2011 12:41:31 -0400 Subject: [icedtea-web] RFC: PR687 Message-ID: <4DA8753B.6040606@redhat.com> Hi, This is a (slightly updated) patch for PR687 [1]. The patch modifies how we try to find the JNLPClassLoader (from which we find the ApplicationInstance). We first search the Context ClassLoader (and it's parents) and then we search the ClassLoader for the classes on the stack (and their parents). Any thoughts or comments? ChangeLog 2011-04-15 Omair Majid * netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java (getApplication): Pass the current thread as a parameter. (getApplication): Add extra argument, Thread. Search the Thread's context classloader and its parent and then search the ClassLoaders, and the parents, of the classes on the stack. (getJnlpClassLoader): New method. (checkExit): Pass current thread as a parameter to getApplication. Cheers, Omair [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 -------------- next part -------------- A non-text attachment was scrubbed... Name: pr687-02.patch Type: text/x-patch Size: 3362 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110415/285fe583/pr687-02.patch From omajid at redhat.com Fri Apr 15 09:56:14 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Apr 2011 12:56:14 -0400 Subject: [icedtea-web] RFC: PR618 - Can't install OpenDJ, JavaWebStart fails with Input stream is null error. In-Reply-To: <4D822201.7000906@redhat.com> References: <4D3F27BE.9060300@redhat.com> <20110126000318.GF18564@rivendell.middle-earth.co.uk> <4D4095C8.4020603@redhat.com> <4D7E2F47.2050807@redhat.com> <20110316204054.GH29289@rivendell.middle-earth.co.uk> <4D822201.7000906@redhat.com> Message-ID: <4DA878AE.8080301@redhat.com> On 03/17/2011 11:00 AM, Omair Majid wrote: > On 03/16/2011 04:40 PM, Dr Andrew John Hughes wrote: >> On 11:07 Mon 14 Mar , Omair Majid wrote: >>> > On 01/26/2011 04:44 PM, Omair Majid wrote: >>>> > > On 01/25/2011 07:03 PM, Dr Andrew John Hughes wrote: >>>>> > >> On 14:42 Tue 25 Jan , Omair Majid wrote: >>>>>> > >>> Hi, >>>>>> > >>> >>>>>> > >>> The attached patch fixes PR618. The issue is that jars >>>>>> marked as lazy >>>>>> > >>> are not currently searched for resources other than classes. >>>>>> So loading >>>>>> > >>> classes from lazy jars works, but loading anything else (zip >>>>>> files in >>>>>> > >>> the case of the bug report) fails. >>>>>> > >>> >>>>>> > >>> The attached patch fixes findResources to use lazy jars if >>>>>> needed. >>>>>> > >>> >>>>>> > >>> URLClassLoader invokes findResource() as a part of its >>>>>> getResource() >>>>>> > >>> implementation. Instead of duplicating the addition of lazy >>>>>> jars in >>>>>> > >>> getResource(), getResource() was removed, and findResource >>>>>> added >>>>>> > >>> instead. findResource() now delegates to findResources(), so >>>>>> there is >>>>>> > >>> only one place where an actual search for resources is >>>>>> performed. >>>>>> > >>> >>>>>> > >>> Any concerns or comments? >>>>>> > >>> >>>>> > >> >>>>>> > >>> diff -r 64da2a80df88 >>>>>> > >>> netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java >>>>>> > >>> --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java >>>>>> Tue Jan >>>>>> > >>> 25 10:19:20 2011 -0500 >>>>>> > >>> +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java >>>>>> Tue Jan >>>>>> > >>> 25 14:42:07 2011 -0500 >>>>>> > >>> @@ -1086,27 +1087,42 @@ >>>>>> > >>> * Finds the resource in this, the parent, or the extension >>>>>> > >>> * class loaders. >>>>>> > >>> */ >>>>>> > >>> - public URL getResource(String name) { >>>>>> > >>> - URL result = super.getResource(name); >>>>>> > >>> - >>>>>> > >>> - for (int i = 1; i< loaders.length; i++) >>>>>> > >>> - if (result == null) >>>>>> > >>> - result = loaders[i].getResource(name); >>>>>> > >>> - >>>>>> > >>> - return result; >>>>>> > >>> + @Override >>>>>> > >>> + public URL findResource(String name) { >>>>>> > >>> + try { >>>>>> > >>> + return findResources(name).nextElement(); >>>>>> > >>> + } catch (NoSuchElementException e) { >>>>>> > >>> + return null; >>>>>> > >>> + } catch (IOException e) { >>>>>> > >>> + return null; >>>>>> > >>> + } >>>>> > >> >>>>> > >> Would it be more efficient to check if there are more elements >>>>> first >>>>> > >> rather than throwing and catching an exception? >>>>> > >> >>>> > > >>>> > > I am not sure about efficiency, but the attached patch fixes it. >>>> > > >> Ok. I think it would be more efficient than generating an exception. >> >>>>>> > >>> @@ -1116,7 +1132,7 @@ >>>>>> > >>> resources.add(e.nextElement()); >>>>>> > >>> } >>>>>> > >>> >>>>>> > >>> - return resources.elements(); >>>>>> > >>> + return resources; >>>>>> > >>> } >>>>> > >> >>>>> > >> Is findResources the only consumer of the resources >>>>> collection? If so, >>>>> > >> it would be >>>>> > >> more efficient to use an ArrayList or LinkedList and avoid the >>>>> > >> implicit synchronisation >>>>> > >> of Vector. >>>>> > >> >>>> > > >>>> > > Yup, findResources is the only method using it. I did not want >>>> to touch >>>> > > original code (at least code that worked), so I left the vector >>>> as it >>>> > > was. I have changed it now. >>>> > > >>>>> > >> What is the reason for returning a List from >>>>> findResourcesBySearching >>>>> > >> rather than just >>>>> > >> an Iterator/Enumeration? AFAICS, you just create an >>>>> enumeration from >>>>> > >> it anyway and >>>>> > >> hasNext()/hasNextElement() would tell you if there are no >>>>> entries. >>>>> > >> >>>> > > >>>> > > Is using an Iterator/Enumeration better than using a List? I am not >>>> > > aware of the differences, and findResourcesBySearching() already >>>> creates >>>> > > a List that I can return. So I thought I would avoid creating an >>>> > > Enumeration based on it until necessary. The attached patch >>>> changes this >>>> > > bit too, though I am not sure I see the advantage. >>>> > > >>> > >>> > Patch updated to apply to head. >>> > >> It restricts what the receiver can do with the List. With just an >> Iterator, >> they can only look at and remove elements (and you can disable the >> latter too >> if necessary). With a List, they have a lot more access they probably >> don't need. >> > > I see your point, but findResourcesBySearching is private, so it > shouldnt be a problem if it exposes more information. > >>> > Thanks, >>> > Omair >>> > diff -r 5454292b3fae >>> netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java >>> > --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Thu >>> Mar 10 15:42:01 2011 -0500 >>> > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Mon >>> Mar 14 11:07:15 2011 -0400 >>> > @@ -40,7 +40,6 @@ >>> > import java.util.List; >>> > import java.util.Map; >>> > import java.util.TreeSet; >>> > -import java.util.Vector; >>> > import java.util.jar.JarEntry; >>> > import java.util.jar.JarFile; >>> > >>> > @@ -1123,31 +1122,54 @@ >>> > /** >>> > * Finds the resource in this, the parent, or the extension >>> > * class loaders. >>> > + * >>> > + * @return aURL for the resource, ornull >>> > + * if the resource could not be found. >>> > */ >>> > - public URL getResource(String name) { >>> > - URL result = super.getResource(name); >>> > + @Override >>> > + public URL findResource(String name) { >>> > + URL result = null; >>> > >>> > - for (int i = 1; i< loaders.length; i++) >>> > - if (result == null) >>> > - result = loaders[i].getResource(name); >>> > + try { >>> > + Enumeration e = findResources(name); >>> > + if (e.hasMoreElements()) { >>> > + result = e.nextElement(); >>> > + } >>> > + } catch (IOException e) { >>> > + // continue >>> > + } >>> > >>> > // If result is still null, look in the codebase loader >>> > if (result == null&& codeBaseLoader != null) >>> > - result = codeBaseLoader.getResource(name); >>> > + result = codeBaseLoader.findResource(name); >>> > >>> > return result; >>> > } >>> > >>> > /** >>> > - * Finds the resource in this, the parent, or the extension >>> > + * Find the resources in this, the parent, or the extension >>> > * class loaders. >>> > */ >>> > @Override >>> > public Enumeration findResources(String name) throws >>> IOException { >>> > - Vector resources = new Vector(); >>> > + Enumeration resources = findResourcesBySearching(name); >>> > + >>> > + // if not found, load all lazy resources; repeat search >>> > + while (!resources.hasMoreElements()&& addNextResource() != null) { >>> > + resources = findResourcesBySearching(name); >>> > + } >>> > + >>> > + return resources; >>> > + } >>> > + >>> > + private Enumeration findResourcesBySearching(String name) >>> throws IOException { >>> > + List resources = new ArrayList(); >>> > Enumeration e; >>> > >>> > for (int i = 0; i< loaders.length; i++) { >>> > + // TODO check if this will blow up or not >>> > + // if loaders[1].getResource() is called, wont it call >>> getResource() on >>> > + // the original caller? infinite recursion? >>> > >>> > if (loaders[i] == this) >>> > e = super.findResources(name); >>> > @@ -1166,7 +1188,7 @@ >>> > resources.add(e.nextElement()); >>> > } >>> > >>> > - return resources.elements(); >>> > + return Collections.enumeration(resources); >> At the top, resources has a type List. So why not just call >> resources.iterator()? >> > > The return type of findResources() has to be an Enumeration (since its > defined by the parent class). If I return an Iterator from > findResourcesBySearching, I will have to perform additional computation > in findResources() to convert the Iterator into an Enumeration. To keep > things simple, I return an enumeration. > Ping. Any thoughts or comments? Cheers, Omair From dlila at redhat.com Fri Apr 15 10:45:46 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 15 Apr 2011 13:45:46 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <243738959.102984.1302809558541.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1936777041.370846.1302889546149.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > I think it might be best to hold this off for now, and hack at it > later. > This was an attempt to make it so that we don't have a bunch of > folders > with just another folder in it. I agree. Well, assuming the patch is now the same as the one before the url hashCode names + my suggestions, it's ok with me. I would be more comfortable if Omair took a look at it first though. It's a big patch and it changes important functionality. Regards, Denis. ----- Original Message ----- > ----- Original Message ----- > > From: "Denis Lila" > > To: "Andrew Su" > > Cc: "IcedTea" , "Omair Majid" > > > > Sent: Thursday, April 14, 2011 1:54:01 PM > > Subject: Re: [RFC][Icedtea-web]: Changed how cache works. > > Hi. > > > > You forgot to hg add CacheLRUWrapper. Assuming it was just a > > rename of the corresponding file in the previous version of > > your patch, I added it to your patch, and attached it. The > > attached patch should compile. > > Oops, thanks for doing that! > > > > > Here are some things that jump out at me (more comments may come > > later on): > > > > In getCacheFileIfExists, can you put the lastPath computation > > in it's own function (similar to getIdForCacheFolder). That way > > it'll be a bit easier to figure out what's going on. > > Sure. > > > > > In removeUntrackedDirectories you do > > > > + for (File f : temp.listFiles()) { > > + String path = f.getPath(); > > + temp = new File(path); > > + if (temp.isDirectory() && !keep.contains(temp.getPath())) { > > + try { > > + FileUtils.recursiveDelete(temp, temp); > > > > Wouldn't it be the same (and simpler) to do: > > > > + for (File f : temp.listFiles()) { > > + if (f.isDirectory() && !keep.contains(f.getPath())) { > > + try { > > + FileUtils.recursiveDelete(f, f); > > > > Yes it would; Residue from moving things around.. > > > Also, the HashSet argument of that function is called > > "keep". > > This is a bit peculiar, since you're deleting everything in it. > > Also, can you make that a Set instead of HashSet? > > Changed. > > > > > > > Most importantly: > > > I have applied your patch and did some adjustments such as using > > > the > > > hash of the url as file name instead of having a really long > > > directory. > > > > Isn't this broken? I mean, what happens when two different urls > > hash to the same code? > > > > > > To me, it seems like you're just going to create a file when it > > is first hashed, and when a different URL has the same hash > > getCachFileIfExist will return the first cached file, instead > > of creating a new one. > > > > -- snip -- > Cheers, > Andrew From dlila at redhat.com Fri Apr 15 12:41:42 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 15 Apr 2011 15:41:42 -0400 (EDT) Subject: [RFC]: Linkage Error fix. In-Reply-To: <107188343.372205.1302894608120.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. Andrew Su pointed out this bug to me a few days ago. In the page http://www-archive.mozilla.org/quality/browser/front-end/testcases/oji/objtest2.html one of the applets does not load once in a while (it happens very often on my machine (>80% of the time)). A LinkageError is thrown. The attached patch fixes it. The problem was that "JNLPClassloader.loadClass" was being called explicitly by the applet instance creation process. That page loads the same applet many times, so there was a race condition where findLoadedClassAll(name) returned null (meaning the class has not been loaded yet), so then we moved on to actually loading it. However by the time we got to the loading code another applet had finished loading the class. Trying to define a class twice in the same classloader is an error. The patch fixes it by not allowing concurrent loading of classes with the same name. Another fix would be to just synchronize the method body on a static lock, but that might be too slow. The only thing I'm worried about with the attached patch is that the map might get a bit big after a while. Is this a realistic concern? If yes, it could be fixed by changing the hash map to , and instead of putting (name, new Object()) in it, I could put(name.hashCode()%83, new Object()). That way key,value pairs would never take up more than about 2Kb, and with 83 locks, I don't think we would have to worry about reduced concurrency. ChangeLog: 2011-04-15 Denis Lila * netx/net/sourceforge/jnlp/Launcher.java Remove unused import. * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java (loadedClassNames): New map. Records all the arguments to loadClass. (loadClass): Does not atomically load classes with identical names. Regards, Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: linkageError.patch Type: text/x-patch Size: 2374 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110415/7114e035/linkageError.patch From dbhole at redhat.com Fri Apr 15 12:55:24 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 15 Apr 2011 15:55:24 -0400 Subject: [RFC]: Linkage Error fix. In-Reply-To: <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <107188343.372205.1302894608120.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110415195524.GA2598@redhat.com> * Denis Lila [2011-04-15 15:43]: > Hi. > > Andrew Su pointed out this bug to me a few days ago. > In the page > http://www-archive.mozilla.org/quality/browser/front-end/testcases/oji/objtest2.html > one of the applets does not load once in a while (it happens > very often on my machine (>80% of the time)). > > A LinkageError is thrown. > > The attached patch fixes it. > > The problem was that "JNLPClassloader.loadClass" was being called > explicitly by the applet instance creation process. That page loads > the same applet many times, so there was a race condition where > findLoadedClassAll(name) returned null (meaning the class has not > been loaded yet), so then we moved on to actually loading it. However > by the time we got to the loading code another applet had finished > loading the class. Trying to define a class twice in the same > classloader is an error. > > The patch fixes it by not allowing concurrent loading of classes > with the same name. Another fix would be to just synchronize > the method body on a static lock, but that might be too slow. > The only thing I'm worried about with the attached patch is that > the map might get a bit big after a while. Is this a realistic concern? > If yes, it could be fixed by changing the hash map to , > and instead of putting (name, new Object()) in it, I could > put(name.hashCode()%83, new Object()). That way key,value pairs would > never take up more than about 2Kb, and with 83 locks, I don't think > we would have to worry about reduced concurrency. > Did you look into how URLCloassLoader and others mitigate the problem? If I am not mistaken, all class load requests go through JNLPClassLoader, and synchronizing on each such call can get expensive. OTOH, if URLClassLoader is doing the same, we are not impacting the performance any further so it'd be okay. As for the patch, comments below: > */ > + private static ConcurrentMap loadedClassNames = new ConcurrentHashMap(); > public Class loadClass(String name) throws ClassNotFoundException { > > + loadedClassNames.putIfAbsent(name, new Object()); I understand the use of Hash* for lookup speed, but seems like a lot of un-necessary object creation is going on here (1 per loaded class). Perhaps only keep an entry for classes loaded by *this* loader by removing the map entry (outside the synchronized block) if its loader was the parent? > + synchronized(loadedClassNames.get(name)) { > Class result = findLoadedClassAll(name); > > // try parent classloader > @@ -1003,7 +1009,7 @@ > // validPackage(name); > > // search this and the extension loaders > - if (result == null) > + if (result == null) { > try { > result = loadClassExt(name); > } catch (ClassNotFoundException cnfe) { > @@ -1060,12 +1066,14 @@ > } > } > } > + } > I take it the extra brackets are just to make it look cleaner? If so, thats fine. > if (result == null) { > throw new ClassNotFoundException(name); > } > > return result; > + } Indentation is incorrect above. Cheers, Deepak From ahughes at redhat.com Fri Apr 15 13:40:38 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 15 Apr 2011 21:40:38 +0100 Subject: [icedtea-web] RFC: Switch to explicit locks and condition queues in PAV In-Reply-To: <1587451938.355749.1302876560850.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110414224253.GN7262@rivendell.middle-earth.co.uk> <1587451938.355749.1302876560850.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110415204038.GG29287@rivendell.middle-earth.co.uk> On 10:09 Fri 15 Apr , Denis Lila wrote: > > This is the change I mentioned in the previous discussion. It replaces > > the use of CHM monitors with explicit locks and condition queues. It > > also > > simplifies (I hope) the panel lock case by using an explicit lock and > > condition queue rather than a mix of the panel object and sleep. > A few comments: > > > @@ -139,25 +144,7 @@ > > // Start the applet > > initEventQueue(panel); > > > > - // Wait for panel to come alive > > - // Wait implemented the long way so that > > - // PluginAppletViewer.waitTillTimeout() needn't be exposed. > > - long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT/1000000; // ns -> ms > > - > > - synchronized(panel) { > > - while (!panel.isAlive() && maxTimeToSleep > 0) { > > - long sleepStart = System.nanoTime(); > > - > > - try { > > - panel.wait(maxTimeToSleep); > > - } catch (InterruptedException e) {} // Just loop back > > - > > - maxTimeToSleep -= (System.nanoTime() - sleepStart)/1000000; // ns -> ms > > - } > > - } > > - > > // Wait for the panel to initialize > > - // (happens in a separate thread) > > PluginAppletViewer.waitForAppletInit(panel); > > > > Applet a = panel.getApplet(); > > The code above wasn't replaced by anything. Was this intentional? > Yes, I think I mentioned it in the ChangeLog. The code is identical to PluginAppletViewer.waitForAppletInit(panel) i.e. we do it twice. > > @@ -691,21 +699,18 @@ > > // FIXME: how do we determine what security context this > > // object should belong to? > > Object o; > > - > > + > > // First, wait for panel to instantiate > > - int waited = 0; > > - while (panel == null && waited < APPLET_TIMEOUT) { > > - try { > > - Thread.sleep(50); > > - waited += 50; > > - } catch (InterruptedException ie) {} // discard, loop back > > - } > > - > > // Next, wait for panel to come alive > > long maxTimeToSleep = APPLET_TIMEOUT; > > - synchronized(panel) { > > - while (!panel.isAlive()) > > - maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); > > + panelLock.lock(); > > + try { > > + while (panel == null || !panel.isAlive()) > > + maxTimeToSleep -= waitTillTimeout(panelLock, panelLive, > > + maxTimeToSleep); > > + } > > + finally { > > + panelLock.unlock(); > > } > > > > // Wait for the panel to initialize > > > I like this. > > I should mention that the new code is not equivalent to the old. > Now we're using a static panelLock while before we were using a different > lock for each panel (i.e. the panel itself). This doesn't seem to be a > problem, but it's worth noting. Yeah this is my concern about applying this. The replacement of the two map locks is trivial. This is kind of messy, but works AFAICS. > > > Long term this class needs a ground-up redesign. We're patching holes > > here when this needs to go back to the drawing board IMHO. > > Won't that reintroduce bugs we've already fixed? Maybe, but you have to trade that off sometimes for long-term maintainability. When it comes to concurrency, it needs to be designed in from the start not patched up on a case-by-case basis. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at redhat.com Fri Apr 15 13:48:30 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Apr 2011 16:48:30 -0400 Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <243738959.102984.1302809558541.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <243738959.102984.1302809558541.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4DA8AF1E.7060302@redhat.com> Hey, While the patch looks fine overall, there are a few changes that I think would be good to have. It's really your call if you want to commit the patch first and then fix them or fix them first. > + /* back-end of how LRU is implemented */ > + private PropertiesFile cacheOrder = new PropertiesFile(new File(cacheDir + File.separator + "RecentlyUsed")); > + Andrew Hughes posted that he would have preferred a name like recently_used instead of RecentlyUsed. Can you please fix this? > + public synchronized boolean addEntry(String identifier, String path) { > + public synchronized boolean removeEntry(String key) { > + public synchronized boolean updateEntry(String oldKey) { I would have been happier with all these methods taking identifiers or keys. As such, there is on way to add an entry and then remove it (as you wouldnt know the key for it). > + @SuppressWarnings("unchecked") > + public synchronized List> getLRUSortedEntries() { Is there a reason to suppress these warnings? > + /* > + * This file is to keep track of the most recently used items. > + * The items are to be kept with > + * key = (current time accessed) followed by folder of item. > + * value = path to file. > + */ > + > + private static final CacheLRUWrapper lruHandler = CacheLRUWrapper.getInstance(); The comment describes an internal representation which is now encapsulated in CacheLRUWrapper. I am also not sure if it is accurate. Please (re)move it. > > + public static void cleanCache() { > + if (okToClearCache()) { > + // First we want to figure out which stuff we need to delete. > + // There should not be any duplicate entries in cacheOrder, since we always clear old when setting new. > + // Thus we don't need to search through that. > + // We now go through all the entries and pick out the ones that aren't marked for delete starting from the back. > + HashSet keep = new HashSet(); is 'keep' used right now? > @@ -754,6 +779,17 @@ > > int size = connection.getContentLength(); > boolean current = CacheUtil.isCurrent(resource.location, resource.requestVersion, connection)&& resource.getUpdatePolicy() != UpdatePolicy.FORCE; > + if (!current) { > + if (entry.isCached()) { > + entry.markForDelete(); > + entry.store(); > + localFile = CacheUtil.makeNewCacheFile(resource.location, resource.downloadVersion); > + CacheEntry newEntry = new CacheEntry(resource.location, resource.requestVersion); > + newEntry.lock(); > + entry.unlock(); > + entry = newEntry; > + } > + } Have you tested this while offline? I am afraid that this might break running jnlp applications offline. Everything else looks fine to me. Cheers, Omair From ahughes at redhat.com Fri Apr 15 13:55:44 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 15 Apr 2011 21:55:44 +0100 Subject: [icedtea-web] RFC: PR618 - Can't install OpenDJ, JavaWebStart fails with Input stream is null error. In-Reply-To: <4DA878AE.8080301@redhat.com> References: <4D3F27BE.9060300@redhat.com> <20110126000318.GF18564@rivendell.middle-earth.co.uk> <4D4095C8.4020603@redhat.com> <4D7E2F47.2050807@redhat.com> <20110316204054.GH29289@rivendell.middle-earth.co.uk> <4D822201.7000906@redhat.com> <4DA878AE.8080301@redhat.com> Message-ID: <20110415205544.GI29287@rivendell.middle-earth.co.uk> On 12:56 Fri 15 Apr , Omair Majid wrote: snip... > > > Ping. Any thoughts or comments? > > Cheers, > Omair Can you start a clean thread with the current version of the patch? The previous e-mail was pretty unreadable for me. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Fri Apr 15 13:58:23 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Fri, 15 Apr 2011 21:58:23 +0100 Subject: DBus font installs [incomplete] In-Reply-To: <20110415143108.GB17759@redhat.com> References: <514115585.346074.1299088413470.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <154001230.347131.1299090878822.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <20110414193254.GH9899@redhat.com> <20110414224819.GO7262@rivendell.middle-earth.co.uk> <20110415143108.GB17759@redhat.com> Message-ID: <20110415205823.GJ29287@rivendell.middle-earth.co.uk> On 10:31 Fri 15 Apr , Deepak Bhole wrote: > * Dr Andrew John Hughes [2011-04-14 18:48]: > > On 15:32 Thu 14 Apr , Deepak Bhole wrote: > > > > + } else { > > > > +diff -r 9d90acd9f99f src/solaris/native/sun/awt/fontpath.c > > > > +--- openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Wed Feb 16 09:39:35 2011 -0500 > > > > ++++ openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Wed Mar 02 09:24:59 2011 -0500 > > > > +@@ -517,11 +517,11 @@ > > > > + } > > > > + > > > > + JNIEXPORT jstring JNICALL Java_sun_font_FontManager_getFontPath > > > > +-(JNIEnv *env, jclass obj, jboolean noType1) { > > > > ++(JNIEnv *env, jclass obj, jboolean noType1, jboolean recheck) { > > > > > > We should find some other way to recheck (whatever it is doing). > > > Changing a public api, even for a sun.* class is a no-no. > > > > > > > For sun.*, it's possible. I'd prefer it to some convoluted workaround. > > > > Wouldn't that make OpenJDK less compatible with (admittedly bad) code > that relies on sun.* API being a certain way? > It's difficult to say without a specific example and there are already many differences between the proprietary JDK and OpenJDK. We can't force Oracle to fix their proprietary JDK, but any such change I'd want to go upstream in OpenJDK, not IcedTea. That's the best we can do. We can't not evolve anything because of the existence of proprietary JDKs. > Deepak -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at redhat.com Fri Apr 15 14:09:17 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Apr 2011 17:09:17 -0400 Subject: [icedtea-web] RFC: PR618 - Can't install OpenDJ, JavaWebStart fails with Input stream is null error. In-Reply-To: <20110415205544.GI29287@rivendell.middle-earth.co.uk> References: <4D3F27BE.9060300@redhat.com> <20110126000318.GF18564@rivendell.middle-earth.co.uk> <4D4095C8.4020603@redhat.com> <4D7E2F47.2050807@redhat.com> <20110316204054.GH29289@rivendell.middle-earth.co.uk> <4D822201.7000906@redhat.com> <4DA878AE.8080301@redhat.com> <20110415205544.GI29287@rivendell.middle-earth.co.uk> Message-ID: <4DA8B3FD.1020002@redhat.com> On 04/15/2011 04:55 PM, Dr Andrew John Hughes wrote: > > Can you start a clean thread with the current version of the patch? > The previous e-mail was pretty unreadable for me. Here you go. Attached. As explained earlier, it fixes PR618, buy allowing lazy loading to work when trying to find resources using getResource(s)/findResource(s). Any thoughts or comments? Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: lazy-load-resources-04.patch Type: text/x-patch Size: 2871 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110415/07d9f1b8/lazy-load-resources-04.patch From dbhole at redhat.com Fri Apr 15 15:57:34 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 15 Apr 2011 18:57:34 -0400 Subject: [icedtea-web] RFC: Patches to make the plugin work with Midori Message-ID: <20110415225734.GB2598@redhat.com> Hi, Midori currently segfaults with the icedtea-web plugin in F15[1]. Attached (first) patch fixes the issue. I discovered an additional issue later related to applet sizing (that I have seen only with Midori so far). Attached (second) patch fixes that issue. The comments in the patch explain why the change is needed. 1: https://bugzilla.redhat.com/show_bug.cgi?id=691259 ChangeLogs: 2011-04-15 Deepak Bhole RH691259: Midori sends a SIGSEGV with the IcedTea NP Plugin * plugin/icedteanp/IcedTeaNPPlugin.cc (NP_Initialize): Rather than returning immediately if already initialized, return after function tables are reset. 2011-04-15 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java (PluginAppletPanelFactory::createPanel): Make the NetxPanel variable final. Resize frame to work around problem whereby AppletViewerPanel doesn't always set the right size initially. Okay for 1.0 (F15 has 1.0.x) and HEAD? Cheers, Deepak From dbhole at redhat.com Fri Apr 15 15:58:19 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 15 Apr 2011 18:58:19 -0400 Subject: [icedtea-web] RFC: Patches to make the plugin work with Midori In-Reply-To: <20110415225734.GB2598@redhat.com> References: <20110415225734.GB2598@redhat.com> Message-ID: <20110415225819.GC2598@redhat.com> Oops, forgot to attach the patches. Attached now. Deepak * Deepak Bhole [2011-04-15 18:57]: > Hi, > > Midori currently segfaults with the icedtea-web plugin in F15[1]. Attached > (first) patch fixes the issue. > > I discovered an additional issue later related to applet sizing (that I > have seen only with Midori so far). Attached (second) patch fixes that > issue. The comments in the patch explain why the change is needed. > > 1: https://bugzilla.redhat.com/show_bug.cgi?id=691259 > > ChangeLogs: > 2011-04-15 Deepak Bhole > > RH691259: Midori sends a SIGSEGV with the IcedTea NP Plugin > * plugin/icedteanp/IcedTeaNPPlugin.cc (NP_Initialize): Rather than > returning immediately if already initialized, return after function tables > are reset. > > 2011-04-15 Deepak Bhole > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java > (PluginAppletPanelFactory::createPanel): Make the NetxPanel variable > final. Resize frame to work around problem whereby AppletViewerPanel > doesn't always set the right size initially. > > > Okay for 1.0 (F15 has 1.0.x) and HEAD? > > Cheers, > Deepak -------------- next part -------------- diff -r b4db997469a2 plugin/icedteanp/IcedTeaNPPlugin.cc --- a/plugin/icedteanp/IcedTeaNPPlugin.cc Thu Apr 14 21:41:32 2011 +0100 +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc Fri Apr 15 18:44:06 2011 -0400 @@ -2009,14 +2009,12 @@ { PLUGIN_DEBUG ("NP_Initialize\n"); - if (initialized) - return NPERR_NO_ERROR; - else if ((browserTable == NULL) || (pluginTable == NULL)) - { - PLUGIN_ERROR ("Browser or plugin function table is NULL."); - - return NPERR_INVALID_FUNCTABLE_ERROR; - } + if ((browserTable == NULL) || (pluginTable == NULL)) + { + PLUGIN_ERROR ("Browser or plugin function table is NULL."); + + return NPERR_INVALID_FUNCTABLE_ERROR; + } // Ensure that the major version of the plugin API that the browser // expects is not more recent than the major version of the API that @@ -2123,6 +2121,12 @@ pluginTable->getvalue = NPP_GetValueProcPtr (ITNP_GetValue); #endif + // Re-setting the above tables multiple times is OK (as the + // browser may change its function locations). However + // anything beyond this point should only run once. + if (initialized) + return NPERR_NO_ERROR; + // Make sure the plugin data directory exists, creating it if // necessary. data_directory = g_strconcat (P_tmpdir, NULL); -------------- next part -------------- diff -r b4db997469a2 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 21:41:32 2011 +0100 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Fri Apr 15 18:44:06 2011 -0400 @@ -122,7 +122,7 @@ long handle, int x, int y, final URL doc, final Hashtable atts) { - NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { + final NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { public NetxPanel run() { NetxPanel panel = new NetxPanel(doc, atts, false); NetxPanel.debug("Using NetX panel"); @@ -171,6 +171,30 @@ PluginDebug.debug("Applet ", a.getClass(), " initialized"); streamhandler.write("instance " + identifier + " reference 0 initialized"); + /* AppletViewerPanel sometimes doesn't set size right initially. This + * causes the parent frame to be the default (10x10) size. + * + * Normally it goes unnoticed since browsers like Firefox make a resize + * call after init. However some browsers (e.g. Midori) don't. + * + * We therefore manually set the parent to the right size. + */ + try { + SwingUtilities.invokeAndWait(new Runnable() { + public void run() { + panel.getParent().setSize(Integer.valueOf(atts.get("width")), Integer.valueOf(atts.get("height"))); + } + }); + } catch (InvocationTargetException ite) { + // Not being able to resize is non-fatal + PluginDebug.debug("Unable to resize panel: "); + ite.printStackTrace(); + } catch (InterruptedException ie) { + // Not being able to resize is non-fatal + PluginDebug.debug("Unable to resize panel: "); + ie.printStackTrace(); + } + AppletSecurityContextManager.getSecurityContext(0).associateSrc(panel.getAppletClassLoader(), doc); AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, panel.getAppletClassLoader()); From omajid at redhat.com Fri Apr 15 16:33:31 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 15 Apr 2011 19:33:31 -0400 Subject: [icedtea-web] RFC: Patches to make the plugin work with Midori In-Reply-To: <20110415225819.GC2598@redhat.com> References: <20110415225734.GB2598@redhat.com> <20110415225819.GC2598@redhat.com> Message-ID: <4DA8D5CB.6080806@redhat.com> On 04/15/2011 06:58 PM, Deepak Bhole wrote: > > * Deepak Bhole [2011-04-15 18:57]: >> > Midori currently segfaults with the icedtea-web plugin in F15[1]. Attached >> > (first) patch fixes the issue. >> > >> > I discovered an additional issue later related to applet sizing (that I >> > have seen only with Midori so far). Attached (second) patch fixes that >> > issue. The comments in the patch explain why the change is needed. >> > >> > 1:https://bugzilla.redhat.com/show_bug.cgi?id=691259 >> > >> > ChangeLogs: >> > 2011-04-15 Deepak Bhole >> > >> > RH691259: Midori sends a SIGSEGV with the IcedTea NP Plugin >> > * plugin/icedteanp/IcedTeaNPPlugin.cc (NP_Initialize): Rather than >> > returning immediately if already initialized, return after function tables >> > are reset. >> > >> > 2011-04-15 Deepak Bhole >> > >> > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java >> > (PluginAppletPanelFactory::createPanel): Make the NetxPanel variable >> > final. Resize frame to work around problem whereby AppletViewerPanel >> > doesn't always set the right size initially. >> > >> > >> > Okay for 1.0 (F15 has 1.0.x) and HEAD? >> > Both patches look good to me. Cheers, Omair From acrux_it at libero.it Fri Apr 15 17:10:56 2011 From: acrux_it at libero.it (acrux) Date: Sat, 16 Apr 2011 02:10:56 +0200 Subject: IcedTea-Web 1.0.2 released! Message-ID: <20110416021056.d1e4be69.acrux_it@libero.it> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi Deepak, i only now saw that sym links: JDK_HOME/jre/bin/itweb-settings -> ../../bin/itweb-settings JDK_HOME/jre/bin/javaws -> ../../bin/javaws are still present whne compiled on ppc64, instead on ppc they are correctly not present anymore. cheers, - --nico - -- GNU/Linux on Power Architecture CRUX PPC - http://cruxppc.org/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEARECAAYFAk2o3pUACgkQxq34tDeO7LgAZQCfS3LjQ7kN0GESeNxI8jWrOort gDgAn2rmJO4bvr9F47STvUjU9/HS8gEG =9TLe -----END PGP SIGNATURE----- From asu at redhat.com Sat Apr 16 16:39:47 2011 From: asu at redhat.com (Andrew Su) Date: Sat, 16 Apr 2011 19:39:47 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <4DA8AF1E.7060302@redhat.com> Message-ID: <580835049.19173.1302997187617.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Omair Majid" > To: "Andrew Su" > Cc: "Denis Lila" , "IcedTea" > Sent: Friday, April 15, 2011 4:48:30 PM > Subject: Re: [RFC][Icedtea-web]: Changed how cache works. > Hey, > > While the patch looks fine overall, there are a few changes that I > think > would be good to have. It's really your call if you want to commit the > patch first and then fix them or fix them first. > > > + /* back-end of how LRU is implemented */ > > + private PropertiesFile cacheOrder = new PropertiesFile(new > > File(cacheDir + File.separator + "RecentlyUsed")); > > + > > Andrew Hughes posted that he would have preferred a name like > recently_used instead of RecentlyUsed. Can you please fix this? Ah yes, this was a part of some changes I did, but forgot to hg add (then forgot to tell Denis when he change file name for me). Fixed. > > > + public synchronized boolean addEntry(String identifier, String > > path) { > > > + public synchronized boolean removeEntry(String key) { > > > + public synchronized boolean updateEntry(String oldKey) { > > I would have been happier with all these methods taking identifiers or > keys. As such, there is on way to add an entry and then remove it (as > you wouldnt know the key for it). I've changed it to take a key for addEntry instead of identifier. > > > + @SuppressWarnings("unchecked") > > + public synchronized List> > > getLRUSortedEntries() { > > Is there a reason to suppress these warnings? Removed > > > + /* > > + * This file is to keep track of the most recently used items. > > + * The items are to be kept with > > + * key = (current time accessed) followed by folder of item. > > + * value = path to file. > > + */ > > + > > + private static final CacheLRUWrapper lruHandler = > > CacheLRUWrapper.getInstance(); > > The comment describes an internal representation which is now > encapsulated in CacheLRUWrapper. I am also not sure if it is accurate. > Please (re)move it. Moved to CacheLRUWrapper. > > > > > + public static void cleanCache() { > > + if (okToClearCache()) { > > + // First we want to figure out which stuff we need to delete. > > + // There should not be any duplicate entries in cacheOrder, since > > we always clear old when setting new. > > + // Thus we don't need to search through that. > > + // We now go through all the entries and pick out the ones that > > aren't marked for delete starting from the back. > > + HashSet keep = new HashSet(); > > is 'keep' used right now? Yup, it's being used to help us remove redundant entries. > > > @@ -754,6 +779,17 @@ > > > > int size = connection.getContentLength(); > > boolean current = > > CacheUtil.isCurrent(resource.location, > > resource.requestVersion, connection)&& > > resource.getUpdatePolicy() != UpdatePolicy.FORCE; > > + if (!current) { > > + if (entry.isCached()) { > > + entry.markForDelete(); > > + entry.store(); > > + localFile = CacheUtil.makeNewCacheFile(resource.location, > > resource.downloadVersion); > > + CacheEntry newEntry = new CacheEntry(resource.location, > > resource.requestVersion); > > + newEntry.lock(); > > + entry.unlock(); > > + entry = newEntry; > > + } > > + } > > Have you tested this while offline? I am afraid that this might break > running jnlp applications offline. If by testing this offline you mean run it using a jnlp file, let it cache, then run jnlp file while disconnected from the internet and still be able to launch it? Then yes, however it fails to launch the cached item. This actually happens with HEAD without my patch too. (Running jnlp file while connected works) > > Everything else looks fine to me. > I've made some minor changes, notably adding an entry for compressed files, since when files are compressed, comparison with extracted file's size against the recorded size will definitely be different (so I avoid this check, have let isCurrent handle the rest by checking last-modified). Thanks for reviewing my patches! Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: patch999.patch Type: text/x-patch Size: 32404 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110416/bb0d9ca2/patch999.patch From bugzilla-daemon at icedtea.classpath.org Sun Apr 17 06:03:33 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 17 Apr 2011 13:03:33 +0000 Subject: [Bug 693] New: Attempting to save a document in Word format causes a crash. Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=693 Summary: Attempting to save a document in Word format causes a crash. Product: IcedTea Version: unspecified Platform: 64-bit OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: IcedTea7 AssignedTo: gnu_andrew at member.fsf.org ReportedBy: bafco001 at btinternet.com CC: unassigned at icedtea.classpath.org Created an attachment (id=516) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=516) The master document Attempting to save an Open Document Format file in any Microsoft file format causes a crash of LibreOffice 3.3.2 The original document was in MS Word 97-2000 doc format but a save of this document also causes a crash. This happens both on a Windows Vista system and on SUSE Linux, both running the latest version of LibreOffice -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 17 06:04:25 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 17 Apr 2011 13:04:25 +0000 Subject: [Bug 693] Attempting to save a document in Word format causes a crash. In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=693 --- Comment #1 from Colin Walls 2011-04-17 13:04:25 --- Created an attachment (id=517) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=517) Error log from the crash This is the traceback from the crash of LibreOffice on a Linux system -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 17 07:52:17 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 17 Apr 2011 14:52:17 +0000 Subject: [Bug 693] Attempting to save a document in Word format causes a crash. In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=693 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #517|text/x-log |text/plain mime type| | -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 17 07:53:44 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 17 Apr 2011 14:53:44 +0000 Subject: [Bug 693] Attempting to save a document in Word format causes a crash. In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=693 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Andrew John Hughes 2011-04-17 14:53:43 --- This is a crash in native LibreOffice code. Please report the bug to them. C [libmswordlx.so+0x61b8c] -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From aph at redhat.com Mon Apr 18 01:45:07 2011 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Apr 2011 09:45:07 +0100 Subject: [RFC]: Linkage Error fix. In-Reply-To: <20110415195524.GA2598@redhat.com> References: <107188343.372205.1302894608120.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110415195524.GA2598@redhat.com> Message-ID: <4DABFA13.2040401@redhat.com> On 15/04/11 20:55, Deepak Bhole wrote: > Did you look into how URLCloassLoader and others mitigate the problem? > If I am not mistaken, all class load requests go through JNLPClassLoader, > and synchronizing on each such call can get expensive. In 1.6 ClassLoader.loadClass() is a synchronized method anyway. There's something of a myth about the expense of synchronization that isn't usually justified by actual measurements. It's usually only a compareAndSwap, and there is little pain for uncontended cases. Avoiding synchronization with more complex schemes may actually be slower; you have to measure it. > OTOH, if URLClassLoader is doing the same, we are not impacting the > performance any further so it'd be okay. This is exactly how ClassLoader does it in 1.7. However, ClassLoader's code is a bit more clear: protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException { synchronized (getClassLoadingLock(name)) { where protected Object getClassLoadingLock(String className) { Object lock = this; if (parallelLockMap != null) { Object newLock = new Object(); lock = parallelLockMap.putIfAbsent(className, newLock); if (lock == null) { lock = newLock; } } return lock; } Andrew. From bugzilla-daemon at icedtea.classpath.org Mon Apr 18 02:22:12 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 18 Apr 2011 09:22:12 +0000 Subject: [Bug 679] YUICompressor crashes with SIGSEGV (0xb) in frame libjvm.so+0x33224c In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=679 --- Comment #7 from Xerxes R?nby 2011-04-18 09:22:12 --- Hi Sebastian, i have not been able to reproduce this bug using xerxes at xerxes-J464X:~/H?mtningar/yuicompressor-2.4.2$ java -version java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9.7) (6b20-1.9.7-0ubuntu1) OpenJDK Server VM (build 19.0-b09, mixed mode My best advice to you are to update the openjdk package in your centoss distribution to a more recent verstion as I belive the bug you are observing allready have been fixed when using a more recent hotspot. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dlila at redhat.com Mon Apr 18 06:37:42 2011 From: dlila at redhat.com (Denis Lila) Date: Mon, 18 Apr 2011 09:37:42 -0400 (EDT) Subject: [RFC]: Linkage Error fix. In-Reply-To: <20110415195524.GA2598@redhat.com> Message-ID: <1561143341.496220.1303133862372.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Did you look into how URLCloassLoader and others mitigate the problem? > If I am not mistaken, all class load requests go through > JNLPClassLoader, > and synchronizing on each such call can get expensive. I did after I read this e-mail. URLClassloader does not override loadClass. ClassLoader implements it, and it's just a synchronized method, which is exactly what I was trying to avoid in this patch. As for synchronization costs: we have a race condition. Some synchronization is unavoidable. The best thing for performance would be to maximize concurrency and making the method synchronized would completely lock it down. My fix avoids that by having a different lock for each class name being loaded. > I understand the use of Hash* for lookup speed, but seems like a lot > of un-necessary object creation is going on here (1 per loaded class). Maybe so, but I don't think this is hurting us in any way. Object instances are very small and if I'm not mistaken their allocation is just bumping a pointer. Their GC costs practically nothing, since if they don't make it into the CHM they'll die as soon as they're created and they won't make it into the old generation. > Perhaps only keep an entry for classes loaded by *this* loader by > removing the map entry (outside the synchronized block) if its loader > was the parent? I'm not sure I understand this. I'll think about it, but I will say that the fix right now is 3 lines, and complicating the logic to any degree to eliminate one "new Object()" per call would be a premature optimization (especially considering how expensive the findLoadedClassAll(name) call is compared to "new Object()"). > > + synchronized(loadedClassNames.get(name)) { > > Class result = findLoadedClassAll(name); > > > > // try parent classloader > > @@ -1003,7 +1009,7 @@ > > // validPackage(name); > > > > // search this and the extension loaders > > - if (result == null) > > + if (result == null) { > > try { > > result = loadClassExt(name); > > } catch (ClassNotFoundException cnfe) { > > @@ -1060,12 +1066,14 @@ > > } > > } > > } > > + } > > > > I take it the extra brackets are just to make it look cleaner? If so, > thats fine. Yeah. It's a pet peeve of mine to put "{}" on all if/for/while. I try to ignore it, but in this case we had a bracketless "if" with a 30+ line body. It was confusing. > > if (result == null) { > > throw new ClassNotFoundException(name); > > } > > > > return result; > > + } > > Indentation is incorrect above. That was intentional. I was trying to make it easier to read. Of course, I'll fix it when I push. Regards, Denis. ----- Original Message ----- > * Denis Lila [2011-04-15 15:43]: > > Hi. > > > > Andrew Su pointed out this bug to me a few days ago. > > In the page > > http://www-archive.mozilla.org/quality/browser/front-end/testcases/oji/objtest2.html > > one of the applets does not load once in a while (it happens > > very often on my machine (>80% of the time)). > > > > A LinkageError is thrown. > > > > The attached patch fixes it. > > > > The problem was that "JNLPClassloader.loadClass" was being called > > explicitly by the applet instance creation process. That page loads > > the same applet many times, so there was a race condition where > > findLoadedClassAll(name) returned null (meaning the class has not > > been loaded yet), so then we moved on to actually loading it. > > However > > by the time we got to the loading code another applet had finished > > loading the class. Trying to define a class twice in the same > > classloader is an error. > > > > The patch fixes it by not allowing concurrent loading of classes > > with the same name. Another fix would be to just synchronize > > the method body on a static lock, but that might be too slow. > > The only thing I'm worried about with the attached patch is that > > the map might get a bit big after a while. Is this a realistic > > concern? > > If yes, it could be fixed by changing the hash map to > Object>, > > and instead of putting (name, new Object()) in it, I could > > put(name.hashCode()%83, new Object()). That way key,value pairs > > would > > never take up more than about 2Kb, and with 83 locks, I don't think > > we would have to worry about reduced concurrency. > > > > > OTOH, if URLClassLoader is doing the same, we are not impacting the > performance any further so it'd be okay. > > As for the patch, comments below: > > > */ > > + private static ConcurrentMap loadedClassNames = > > new ConcurrentHashMap(); > > public Class loadClass(String name) throws > > ClassNotFoundException { > > > > + loadedClassNames.putIfAbsent(name, new Object()); > > > > > Cheers, > Deepak From dlila at redhat.com Mon Apr 18 06:47:25 2011 From: dlila at redhat.com (Denis Lila) Date: Mon, 18 Apr 2011 09:47:25 -0400 (EDT) Subject: [RFC]: Linkage Error fix. In-Reply-To: <4DABFA13.2040401@redhat.com> Message-ID: <974723305.496445.1303134445336.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> I guess I should have read this before I responded to Deepak. > This is exactly how ClassLoader does it in 1.7. However, > ClassLoader's code is a bit more clear: > > protected Class loadClass(String name, boolean resolve) > throws ClassNotFoundException > { > synchronized (getClassLoadingLock(name)) { > > where > > protected Object getClassLoadingLock(String className) { > Object lock = this; > if (parallelLockMap != null) { > Object newLock = new Object(); > lock = parallelLockMap.putIfAbsent(className, newLock); > if (lock == null) { > lock = newLock; > } > } > return lock; > } Interesting. That's almost exactly the same as my solution (although, I don't know if it's clearer ;-). In my e-mail with the patch I expressed some concern over the CHM getting too large after a while, and as a fix I proposed having one lock per class_name.hashCode() % small_prime_number instead of one lock for every class name. What do you think about this? Regards, Denis. ----- Original Message ----- > On 15/04/11 20:55, Deepak Bhole wrote: > > > Did you look into how URLCloassLoader and others mitigate the > > problem? > > If I am not mistaken, all class load requests go through > > JNLPClassLoader, > > and synchronizing on each such call can get expensive. > > In 1.6 ClassLoader.loadClass() is a synchronized method anyway. > > There's something of a myth about the expense of synchronization that > isn't usually justified by actual measurements. It's usually only a > compareAndSwap, and there is little pain for uncontended cases. > Avoiding synchronization with more complex schemes may actually be > slower; you have to measure it. > > > OTOH, if URLClassLoader is doing the same, we are not impacting the > > performance any further so it'd be okay. > > > Andrew. From aph at redhat.com Mon Apr 18 07:03:12 2011 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Apr 2011 15:03:12 +0100 Subject: [RFC]: Linkage Error fix. In-Reply-To: <974723305.496445.1303134445336.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <974723305.496445.1303134445336.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4DAC44A0.4070901@redhat.com> On 04/18/2011 02:47 PM, Denis Lila wrote: > I guess I should have read this before I responded to Deepak. > >> This is exactly how ClassLoader does it in 1.7. However, >> ClassLoader's code is a bit more clear: >> >> protected Class loadClass(String name, boolean resolve) >> throws ClassNotFoundException >> { >> synchronized (getClassLoadingLock(name)) { >> >> where >> >> protected Object getClassLoadingLock(String className) { >> Object lock = this; >> if (parallelLockMap != null) { >> Object newLock = new Object(); >> lock = parallelLockMap.putIfAbsent(className, newLock); >> if (lock == null) { >> lock = newLock; >> } >> } >> return lock; >> } Eww, nasty mailer broke indentation. :-( > Interesting. That's almost exactly the same as my solution > (although, I don't know if it's clearer ;-). > > In my e-mail with the patch I expressed some concern over > the CHM getting too large after a while, and as a fix I > proposed having one lock per class_name.hashCode() % small_prime_number > instead of one lock for every class name. What do you > think about this? I think you are getting way past what this problem actually needs. Ask yourself: will anyone ever notice the difference caused by making this class loader concurrent? is it possible actually to measure the performance difference from simply making the method synchronized? If the answer to both these questions is "no", you know what to do... Andrew. From omajid at redhat.com Mon Apr 18 07:20:28 2011 From: omajid at redhat.com (Omair Majid) Date: Mon, 18 Apr 2011 10:20:28 -0400 Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <580835049.19173.1302997187617.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <580835049.19173.1302997187617.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4DAC48AC.8040000@redhat.com> On 04/16/2011 07:39 PM, Andrew Su wrote: > > >>> >>>>> + public synchronized boolean addEntry(String identifier, >>>>> String path) { >>> >>>>> + public synchronized boolean removeEntry(String key) { >>> >>>>> + public synchronized boolean updateEntry(String oldKey) { >>> >>> I would have been happier with all these methods taking >>> identifiers or keys. As such, there is on way to add an entry and >>> then remove it (as you wouldnt know the key for it). > I've changed it to take a key for addEntry instead of identifier. I dont think this is the right way. Now the implementation knowledge is spread across multiple classes. If you change the key in makeNewCacheFile, CacheLRUWrapper will need need to be updated too :( Perhaps a fix would be to create a method like generateKey(Sting path) in CacheLRUWrapper? The key returned by this method would be used in addEntry. >>> >>> Have you tested this while offline? I am afraid that this might >>> break running jnlp applications offline. > If by testing this offline you mean run it using a jnlp file, let it > cache, then run jnlp file while disconnected from the internet and > still be able to launch it? Then yes, however it fails to launch the > cached item. This actually happens with HEAD without my patch too. > (Running jnlp file while connected works) > Ugh. That sucks :( I know this was working in Feburary (my demos at FOSDEM were running offline). I wonder if I accidentally broke it. >>> >>> Everything else looks fine to me. >>> > I've made some minor changes, notably adding an entry for compressed > files, since when files are compressed, comparison with extracted > file's size against the recorded size will definitely be different > (so I avoid this check, have let isCurrent handle the rest by > checking last-modified). > Are the markCompressed/isCompressed methods used anywhere? If not, could you please make that a separate patch? > Thanks for reviewing my patches! > No problem! Cheers, Omair From dlila at redhat.com Mon Apr 18 07:21:54 2011 From: dlila at redhat.com (Denis Lila) Date: Mon, 18 Apr 2011 10:21:54 -0400 (EDT) Subject: [RFC]: Linkage Error fix. In-Reply-To: <4DAC44A0.4070901@redhat.com> Message-ID: <598409977.508500.1303136514659.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > I think you are getting way past what this problem actually needs. > Ask yourself: will anyone ever notice the difference caused by making > this class loader concurrent? is it possible actually to measure the > performance difference from simply making the method synchronized? If > the answer to both these questions is "no", you know what to do... Hm... yeah, you're right. The new patch is attached. Thank you, Denis. ----- Original Message ----- > On 04/18/2011 02:47 PM, Denis Lila wrote: > > I guess I should have read this before I responded to Deepak. > > > >> This is exactly how ClassLoader does it in 1.7. However, > >> ClassLoader's code is a bit more clear: > >> > >> protected Class loadClass(String name, boolean resolve) > >> throws ClassNotFoundException > >> { > >> synchronized (getClassLoadingLock(name)) { > >> > >> where > >> > >> protected Object getClassLoadingLock(String className) { > >> Object lock = this; > >> if (parallelLockMap != null) { > >> Object newLock = new Object(); > >> lock = parallelLockMap.putIfAbsent(className, newLock); > >> if (lock == null) { > >> lock = newLock; > >> } > >> } > >> return lock; > >> } > > Eww, nasty mailer broke indentation. :-( > > > Interesting. That's almost exactly the same as my solution > > (although, I don't know if it's clearer ;-). > > > > In my e-mail with the patch I expressed some concern over > > the CHM getting too large after a while, and as a fix I > > proposed having one lock per class_name.hashCode() % > > small_prime_number > > instead of one lock for every class name. What do you > > think about this? > > > Andrew. -------------- next part -------------- A non-text attachment was scrubbed... Name: linkageError.patch Type: text/x-patch Size: 2352 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110418/aac035f8/linkageError.patch From andrew at icedtea.classpath.org Mon Apr 18 08:29:48 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Mon, 18 Apr 2011 15:29:48 +0000 Subject: /hg/icedtea: Bump to b130. Add script to remove in-tree libraries. Message-ID: changeset fef8fe66fdf5 in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=fef8fe66fdf5 author: Andrew John Hughes date: Mon Apr 18 16:29:18 2011 +0100 Bump to b130. Add script to remove in-tree libraries. 2011-04-18 Andrew John Hughes * patches/icedtea-freetypeversion.patch: Moved upstream. * patches/icedtea-jdk-use-ssize_t.patch: No longer applicable (patched file was part of HPI which is now gone). * .hgignore: Don't hide scripts. * Makefile.am: (OPENJDK_VERSION): Bump to b130. (CORBA_CHANGESET): Updated. (HOTSPOT_CHANGESET): Likewise. (JAXP_CHANGESET): Likewise. (JAXWS_CHANGESET): Likewise. (JDK_CHANGESET): Likewise. (LANGTOOLS_CHANGESET): Likewise. (OPENJDK_CHANGESET): Likewise. (CORBA_SHA256SUM): Likewise. (HOTSPOT_SHA256SUM): Likewise. (JAXP_SHA256SUM): Likewise. (JAXWS_SHA256SUM): Likewise. (JDK_SHA256SUM): Likewise. (LANGTOOLS_SHA256SUM): Likewise. (OPENJDK_SHA256SUM): Likewise. (JAXWS_DROP_ZIP): Likewise. (JAXWS_DROP_SHA256SUM): Likewise. (JAXP_DROP_ZIP): Likewise. (JAXP_DROP_SHA256SUM): Likewise. (ICEDTEA_PATCHES): Drop above patches. (ICEDTEA_BOOT_PATCHES): Add multicatch and trywithresources patches. (.PHONY): Add clean-remove- intree-libraries. (extract): Depend on remove-intree- libraries. (clean-extract-openjdk): Depend on clean-remove- intree-libraries. (remove-intree-libraries): Run a script to remove intree copies of libjpeg, zlib, libpng and giflib. (clean-remove-intree-libraries): Remove the stamp. (versioning): Don't alter the original file as it may be hardlinked to an OpenJDK source tree. Move the original and create a new file. * patches/boot/ecj-diamond.patch: Extended with new cases. * patches/boot/ecj-multicatch.patch: Remove instances of multicatch (Project Coin feature). * patches/boot/ecj-stringswitch.patch: Extended with new cases. * patches/boot/ecj-trywithresources.patch: Remove instances of try-with-resources (Project Coin feature). * patches/boot/fontconfig.patch: Regenerated. * patches/boot/revert-6973616.patch: Likewise. * patches/boot/xbootclasspath.patch: Likewise. * patches/hotspot/default/icedtea-text-relocations.patch: Likewise. * patches/icedtea-libraries.patch: Drop removal of libjpeg files from patch. Now achieved using remove-intree- libraries script. * patches/systemtap-alloc-size-workaround.patch: Regenerated. * remove-intree-libraries.sh: New script to remove intree libraries. diffstat: .hgignore | 2 +- ChangeLog | 58 + Makefile.am | 61 +- patches/boot/ecj-diamond.patch | 4651 ++- patches/boot/ecj-multicatch.patch | 67 + patches/boot/ecj-stringswitch.patch | 177 +- patches/boot/ecj-trywithresources.patch | 201 + patches/boot/fontconfig.patch | 6 +- patches/boot/revert-6973616.patch | 8 +- patches/boot/xbootclasspath.patch | 18 +- patches/hotspot/default/icedtea-text-relocations.patch | 18 +- patches/icedtea-freetypeversion.patch | 11 - patches/icedtea-jdk-use-ssize_t.patch | 32 - patches/icedtea-libraries.patch | 24217 --------------- patches/systemtap-alloc-size-workaround.patch | 13 +- remove-intree-libraries.sh | 60 + 16 files changed, 5152 insertions(+), 24448 deletions(-) diffs (truncated from 30376 to 500 lines): diff -r 7f137bd40e46 -r fef8fe66fdf5 .hgignore --- a/.hgignore Wed Mar 30 01:27:14 2011 +0100 +++ b/.hgignore Mon Apr 18 16:29:18 2011 +0100 @@ -10,4 +10,4 @@ config.status install-sh Makefile.in -*.sh + diff -r 7f137bd40e46 -r fef8fe66fdf5 ChangeLog --- a/ChangeLog Wed Mar 30 01:27:14 2011 +0100 +++ b/ChangeLog Mon Apr 18 16:29:18 2011 +0100 @@ -1,3 +1,61 @@ +2011-04-18 Andrew John Hughes + + * patches/icedtea-freetypeversion.patch: + Moved upstream. + * patches/icedtea-jdk-use-ssize_t.patch: + No longer applicable (patched file was + part of HPI which is now gone). + * .hgignore: Don't hide scripts. + * Makefile.am: + (OPENJDK_VERSION): Bump to b130. + (CORBA_CHANGESET): Updated. + (HOTSPOT_CHANGESET): Likewise. + (JAXP_CHANGESET): Likewise. + (JAXWS_CHANGESET): Likewise. + (JDK_CHANGESET): Likewise. + (LANGTOOLS_CHANGESET): Likewise. + (OPENJDK_CHANGESET): Likewise. + (CORBA_SHA256SUM): Likewise. + (HOTSPOT_SHA256SUM): Likewise. + (JAXP_SHA256SUM): Likewise. + (JAXWS_SHA256SUM): Likewise. + (JDK_SHA256SUM): Likewise. + (LANGTOOLS_SHA256SUM): Likewise. + (OPENJDK_SHA256SUM): Likewise. + (JAXWS_DROP_ZIP): Likewise. + (JAXWS_DROP_SHA256SUM): Likewise. + (JAXP_DROP_ZIP): Likewise. + (JAXP_DROP_SHA256SUM): Likewise. + (ICEDTEA_PATCHES): Drop above patches. + (ICEDTEA_BOOT_PATCHES): Add multicatch + and trywithresources patches. + (.PHONY): Add clean-remove-intree-libraries. + (extract): Depend on remove-intree-libraries. + (clean-extract-openjdk): Depend on clean-remove-intree-libraries. + (remove-intree-libraries): Run a script to remove + intree copies of libjpeg, zlib, libpng and giflib. + (clean-remove-intree-libraries): Remove the stamp. + (versioning): Don't alter the original file as it may + be hardlinked to an OpenJDK source tree. Move the original + and create a new file. + * patches/boot/ecj-diamond.patch: Extended with new cases. + * patches/boot/ecj-multicatch.patch: Remove instances of + multicatch (Project Coin feature). + * patches/boot/ecj-stringswitch.patch: Extended with new cases. + * patches/boot/ecj-trywithresources.patch: Remove instances + of try-with-resources (Project Coin feature). + * patches/boot/fontconfig.patch: Regenerated. + * patches/boot/revert-6973616.patch: Likewise. + * patches/boot/xbootclasspath.patch: Likewise. + * patches/hotspot/default/icedtea-text-relocations.patch: Likewise. + * patches/icedtea-libraries.patch: + Drop removal of libjpeg files from patch. Now + achieved using remove-intree-libraries script. + * patches/systemtap-alloc-size-workaround.patch: + Regenerated. + * remove-intree-libraries.sh: New script to remove + intree libraries. + 2011-03-29 Andrew John Hughes PR616, PR99: Don't statically link libstdc++ diff -r 7f137bd40e46 -r fef8fe66fdf5 Makefile.am --- a/Makefile.am Wed Mar 30 01:27:14 2011 +0100 +++ b/Makefile.am Mon Apr 18 16:29:18 2011 +0100 @@ -1,22 +1,22 @@ # Dependencies -OPENJDK_VERSION = b123 +OPENJDK_VERSION = b130 -CORBA_CHANGESET = eac2b25431d9 -HOTSPOT_CHANGESET = 011f8af78ea1 -JAXP_CHANGESET = 17aa584100e9 -JAXWS_CHANGESET = 98bca2ec154b -JDK_CHANGESET = 3b8e4a1215bb -LANGTOOLS_CHANGESET = a75f9777ae63 -OPENJDK_CHANGESET = 714f89350919 +CORBA_CHANGESET = 59f02c101698 +HOTSPOT_CHANGESET = bbfa41dad6d4 +JAXP_CHANGESET = b6f201c0649a +JAXWS_CHANGESET = 4c04de31900b +JDK_CHANGESET = d5404dcb1265 +LANGTOOLS_CHANGESET = 4659da7bff78 +OPENJDK_CHANGESET = d39d0c08731a -CORBA_SHA256SUM = 106b6ff3765db0d608a7e5542a7b606fe10a2c1ebb155b866aef09f88ce481a7 -HOTSPOT_SHA256SUM = cb89a70159a7f124904ecaf17683a5709787e079f476faea4e11645e4676c44d -JAXP_SHA256SUM = 009baa056f2b01e313470b71542b40baab511e179b63decca00b16081e6730bd -JAXWS_SHA256SUM = 5990beb8e8f2144838d52f0948b088bf74ae3ddd748b996ddbb7e7ff1605389b -JDK_SHA256SUM = 5ad0f1d0c4b4ae32675d530d5d786f5b81083fa6a51cb24a823a229f366241b7 -LANGTOOLS_SHA256SUM = c60849a838df72cb7b95562a97af75fa1e3e56fcc15678885a8e154463df8417 -OPENJDK_SHA256SUM = 66137d24a545e15f7be6925ebf92e456c4a42e7c862db2f6eb12cafb8cd4288b +CORBA_SHA256SUM = 4c6db5299947c3ed11a7f72da55a3cd89197c143f10d77c75036aa2f2cf296a6 +HOTSPOT_SHA256SUM = bf4f93ae5782e4110ffc33fdc997c4c43f798eca9dff6db4784f8da51ff0f2c3 +JAXP_SHA256SUM = a1a5c6b2671f83d4675f9ba25013c6a16a4cf4d1040fcd2ff4143c92bd5496a3 +JAXWS_SHA256SUM = 8fe84a61142d579487bee98133fc26e57aedb97f781dc925ad3803aa40f5c061 +JDK_SHA256SUM = 78ff05e5128898830612dd117e7799f982663132d5fb518835cc5871a18d0427 +LANGTOOLS_SHA256SUM = 1df1bb1edd5f912405398c0024f8290f6a9030172dd1196c52e2c461769a1a07 +OPENJDK_SHA256SUM = 937930cb6c3174f8bdbf3d0034832fbde539fd62591087f1d6fcec695ed20519 CACAO_VERSION = e321b101a9ee CACAO_SHA256SUM = 46bc5b6212c199dc4a3dbebe6386fe15a8248625a5dffa17115aab394a298444 @@ -25,14 +25,14 @@ CACAO_SRC_ZIP = cacao-$(CACAO_VERSION).tar.bz2 JAXWS_DROP_URL = http://icedtea.classpath.org/download/drops -JAXWS_DROP_ZIP = jdk7-jaxws2_2-2010_08_19.zip -JAXWS_DROP_SHA256SUM = b8877aafbb15a348babcaee4ee372fb3e2ea0282f8fe93d306272fd24d7847de +JAXWS_DROP_ZIP = jdk7-jaxws2_2_2-2010_12_14.zip +JAXWS_DROP_SHA256SUM = ef3115dde8ed9a7129e65aab8b1499e11621e343559e6e5a8df9c4542848fb9b JAF_DROP_URL = http://icedtea.classpath.org/download/drops JAF_DROP_ZIP = jdk7-jaf-2010_08_19.zip JAF_DROP_SHA256SUM = e6aefedfdbb4673e8019583d1344fb162b94e1b10382c362364dbbfd5889c09e JAXP_DROP_URL = http://icedtea.classpath.org/download/drops -JAXP_DROP_ZIP = jaxp-1_4_4.zip -JAXP_DROP_SHA256SUM = 10b203bec5b7d3dd8f515a9e098f80abc316faf977bcc220b56efe3dc6e9e5e9 +JAXP_DROP_ZIP = jaxp-1_4_5-dev.zip +JAXP_DROP_SHA256SUM = 938cce9d3f0afaa5d076c62a2de081862102d10bfe04a0767122f2dff5bd975e ICEDTEA_HG_URL = http://hg.openjdk.java.net/icedtea/jdk7 OPENJDK_HG_URL = http://hg.openjdk.java.net/jdk7/jdk7 @@ -249,7 +249,6 @@ patches/icedtea-print-lsb-release.patch \ patches/icedtea-jpegclasses.patch \ patches/debian/icedtea-uname.patch \ - patches/icedtea-freetypeversion.patch \ patches/hotspot/$(HSBUILD)/icedtea-sparc-ptracefix.patch \ patches/hotspot/$(HSBUILD)/icedtea-sparc-trapsfix.patch \ patches/icedtea-override-redirect-metacity.patch \ @@ -257,7 +256,6 @@ patches/icedtea-hotspot-gcc-pr36917.patch \ patches/icedtea-alpha-fixes.patch \ patches/icedtea-alt-jar.patch \ - patches/icedtea-jdk-use-ssize_t.patch \ patches/hotspot/$(HSBUILD)/icedtea-use-idx_t.patch \ patches/hotspot/$(HSBUILD)/icedtea-params-cast-size_t.patch \ patches/icedtea-clean-crypto.patch \ @@ -362,7 +360,9 @@ patches/boot/corba-dependencies.patch \ patches/boot/jaxws-langtools-dependency.patch \ patches/boot/jaxws-jdk-dependency.patch \ - patches/boot/hotspot-jdk-dependency.patch + patches/boot/hotspot-jdk-dependency.patch \ + patches/boot/ecj-multicatch.patch \ + patches/boot/ecj-trywithresources.patch if CP39408_JAVAH ICEDTEA_BOOT_PATCHES += patches/boot/icedtea-pr39408.patch @@ -730,7 +730,7 @@ clean-bootstrap-directory-symlink-stage1 icedtea icedtea-debug \ clean-icedtea icedtea-stage2 clean-icedtea-boot \ clean-rt hotspot hotspot-helper clean-jtreg clean-jtreg-reports \ - clean-drops jtregcheck + clean-drops jtregcheck clean-remove-intree-libraries env: @echo 'unset JAVA_HOME' @@ -1073,7 +1073,8 @@ rm -f stamps/download-cacao.stamp stamps/extract.stamp: stamps/extract-openjdk.stamp \ - stamps/extract-cacao.stamp stamps/extract-jaxws.stamp + stamps/extract-cacao.stamp stamps/extract-jaxws.stamp \ + stamps/remove-intree-libraries.stamp mkdir -p stamps touch $@ @@ -1191,7 +1192,7 @@ touch $@ clean-extract-openjdk: clean-overlay clean-versioning \ - clean-patch-fsg + clean-patch-fsg clean-remove-intree-libraries rm -rf openjdk rm -f stamps/extract-openjdk.stamp @@ -1237,6 +1238,13 @@ mkdir -p stamps rm -f stamps/extract-jaxws.stamp +stamps/remove-intree-libraries.stamp: stamps/extract-openjdk.stamp + sh $(srcdir)/remove-intree-libraries.sh + touch stamps/remove-intree-librares.stamp + +clean-remove-intree-libraries: + rm -f stamps/remove-intree-libraries.stamp + stamps/generated.stamp: stamps/extract.stamp set -e ; \ if [ ! -e $(abs_top_builddir)/generated.build ]; then \ @@ -1380,7 +1388,8 @@ fi stamps/versioning.stamp: stamps/patch.stamp - cp openjdk/jdk/make/common/shared/Defs.gmk Defs.gmk.bak + mv openjdk/jdk/make/common/shared/Defs.gmk Defs.gmk.bak + cat Defs.gmk.bak > openjdk/jdk/make/common/shared/Defs.gmk icedtea_version="$(PACKAGE_VERSION)$(ICEDTEA_REV)" ; \ if ! test "x$(WITH_CACAO)" = "xno"; then \ echo "JDK_DERIVATIVE_NAME=$${icedtea_version}" \ diff -r 7f137bd40e46 -r fef8fe66fdf5 patches/boot/ecj-diamond.patch --- a/patches/boot/ecj-diamond.patch Wed Mar 30 01:27:14 2011 +0100 +++ b/patches/boot/ecj-diamond.patch Mon Apr 18 16:29:18 2011 +0100 @@ -1,14 +1,14 @@ diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Attribute.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Attribute.java ---- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Attribute.java 2011-03-14 22:10:30.000000000 +0000 -+++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Attribute.java 2011-03-16 22:41:33.034195793 +0000 +--- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Attribute.java 2011-04-11 12:34:30.000000000 +0100 ++++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Attribute.java 2011-04-13 15:10:03.590190441 +0100 @@ -104,9 +104,9 @@ + return this.def.compareTo(that.def); } - private static final byte[] noBytes = {}; - private static final Map, List> canonLists = new HashMap<>(); - private static final Map attributes = new HashMap<>(); - private static final Map standardDefs = new HashMap<>(); -+ private static final Map, List> canonLists = new HashMap,List>(); ++ private static final Map, List> canonLists = new HashMap, List>(); + private static final Map attributes = new HashMap(); + private static final Map standardDefs = new HashMap(); @@ -44,46 +44,172 @@ attributes.remove(a); return a; } -@@ -832,7 +832,7 @@ +@@ -838,7 +838,7 @@ */ static //private Layout.Element[] tokenizeLayout(Layout self, int curCble, String layout) { -- ArrayList col = new ArrayList<>(layout.length()); -+ ArrayList col = new ArrayList(layout.length()); +- List col = new ArrayList<>(layout.length()); ++ List col = new ArrayList(layout.length()); tokenizeLayout(self, curCble, layout, col); Layout.Element[] res = new Layout.Element[col.size()]; col.toArray(res); -@@ -897,7 +897,7 @@ +@@ -903,7 +903,7 @@ case 'T': // union: 'T' any_int union_case* '(' ')' '[' body ']' kind = EK_UN; i = tokenizeSInt(e, layout, i); -- ArrayList cases = new ArrayList<>(); -+ ArrayList cases = new ArrayList(); +- List cases = new ArrayList<>(); ++ List cases = new ArrayList(); for (;;) { // Keep parsing cases until we hit the default case. if (layout.charAt(i++) != '(') -@@ -1051,7 +1051,7 @@ +@@ -1057,7 +1057,7 @@ } static //private String[] splitBodies(String layout) { -- ArrayList bodies = new ArrayList<>(); -+ ArrayList bodies = new ArrayList(); +- List bodies = new ArrayList<>(); ++ List bodies = new ArrayList(); // Parse several independent layout bodies: "[foo][bar]...[baz]" for (int i = 0; i < layout.length(); i++) { if (layout.charAt(i++) != '[') +diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/BandStructure.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/BandStructure.java +--- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/BandStructure.java 2011-04-12 00:18:33.000000000 +0100 ++++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/BandStructure.java 2011-04-13 15:10:03.606190699 +0100 +@@ -257,7 +257,7 @@ + assert(basicCodings[_meta_default] == null); + assert(basicCodings[_meta_canon_min] != null); + assert(basicCodings[_meta_canon_max] != null); +- Map map = new HashMap<>(); ++ Map map = new HashMap(); + for (int i = 0; i < basicCodings.length; i++) { + Coding c = basicCodings[i]; + if (c == null) continue; +@@ -1050,8 +1050,8 @@ + + // Bootstrap support for CPRefBands. These are needed to record + // intended CP indexes, before the CP has been created. +- private final List allKQBands = new ArrayList<>(); +- private List needPredefIndex = new ArrayList<>(); ++ private final List allKQBands = new ArrayList(); ++ private List needPredefIndex = new ArrayList(); + + + int encodeRef(Entry e, Index ix) { +@@ -1686,7 +1686,7 @@ + protected int attrClassFileVersionMask; + + // Mapping from Attribute.Layout to Band[] (layout element bands). +- protected Map attrBandTable = new HashMap<>(); ++ protected Map attrBandTable = new HashMap(); + + // Well-known attributes: + protected final Attribute.Layout attrCodeEmpty; +@@ -1695,11 +1695,11 @@ + protected final Attribute.Layout attrConstantValue; + + // Mapping from Attribute.Layout to Integer (inverse of attrDefs) +- Map attrIndexTable = new HashMap<>(); ++ Map attrIndexTable = new HashMap(); + + // Mapping from attribute index (<32 are flag bits) to attributes. + protected List> attrDefs = +- new FixedList<>(ATTR_CONTEXT_LIMIT); ++ new FixedList>(ATTR_CONTEXT_LIMIT); + { + for (int i = 0; i < ATTR_CONTEXT_LIMIT; i++) { + assert(attrIndexLimit[i] == 0); +@@ -1894,7 +1894,7 @@ + + protected List getPredefinedAttrs(int ctype) { + assert(attrIndexLimit[ctype] != 0); +- List res = new ArrayList<>(attrIndexLimit[ctype]); ++ List res = new ArrayList(attrIndexLimit[ctype]); + // Remove nulls and non-predefs. + for (int ai = 0; ai < attrIndexLimit[ctype]; ai++) { + if (testBit(attrDefSeen[ctype], 1L<(); ++ prevForAssertMap = new HashMap(); + prevForAssertMap.put(b, p); + return true; + } +diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/ClassReader.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/ClassReader.java +--- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/ClassReader.java 2011-04-12 00:18:33.000000000 +0100 ++++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/ClassReader.java 2011-04-13 15:10:03.606190699 +0100 +@@ -469,7 +469,7 @@ + + void readInnerClasses(Class cls) throws IOException { + int nc = readUnsignedShort(); +- ArrayList ics = new ArrayList<>(nc); ++ ArrayList ics = new ArrayList(nc); + for (int i = 0; i < nc; i++) { + InnerClass ic = + new InnerClass(readClassRef(), +diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java +--- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java 2011-04-12 00:18:33.000000000 +0100 ++++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/CodingChooser.java 2011-04-13 15:10:03.606190699 +0100 +@@ -743,9 +743,9 @@ + // Steps 1/2/3 are interdependent, and may be iterated. + // Steps 4 and 5 may be decided independently afterward. + int[] LValuesCoded = PopulationCoding.LValuesCoded; +- List bestFits = new ArrayList<>(); +- List fullFits = new ArrayList<>(); +- List longFits = new ArrayList<>(); ++ List bestFits = new ArrayList(); ++ List fullFits = new ArrayList(); ++ List longFits = new ArrayList(); + final int PACK_TO_MAX_S = 1; + if (bestPopFVC <= 255) { + bestFits.add(BandStructure.BYTE1); +@@ -785,7 +785,7 @@ + } + } + } +- List allFits = new ArrayList<>(); ++ List allFits = new ArrayList(); + for (Iterator i = bestFits.iterator(), + j = fullFits.iterator(), + k = longFits.iterator(); +@@ -1230,10 +1230,10 @@ + Histogram hist = getValueHistogram(); + int fVlen = stressLen(hist.getTotalLength()); + if (fVlen == 0) return coding; +- List popvals = new ArrayList<>(); ++ List popvals = new ArrayList(); + if (stress.nextBoolean()) { + // Build the population from the value list. +- Set popset = new HashSet<>(); ++ Set popset = new HashSet(); + for (int i = start; i < end; i++) { + if (popset.add(values[i])) popvals.add(values[i]); + } +diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Coding.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Coding.java +--- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Coding.java 2011-04-12 00:18:33.000000000 +0100 ++++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Coding.java 2011-04-13 15:10:03.606190699 +0100 +@@ -402,7 +402,7 @@ + private static Map codeMap; + + private static synchronized Coding of(int B, int H, int S, int del) { +- if (codeMap == null) codeMap = new HashMap<>(); ++ if (codeMap == null) codeMap = new HashMap(); + Coding x0 = new Coding(B, H, S, del); + Coding x1 = codeMap.get(x0); + if (x1 == null) codeMap.put(x0, x1 = x0); diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java ---- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java 2011-03-14 22:10:30.000000000 +0000 -+++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java 2011-03-16 22:41:33.034195793 +0000 -@@ -916,7 +916,7 @@ +--- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java 2011-04-11 23:07:01.000000000 +0100 ++++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/ConstantPool.java 2011-04-13 15:10:03.606190699 +0100 +@@ -919,7 +919,7 @@ public static Index[] partition(Index ix, int[] keys) { // %%% Should move this into class Index. -- ArrayList> parts = new ArrayList<>(); -+ ArrayList> parts = new ArrayList>(); +- List> parts = new ArrayList<>(); ++ List> parts = new ArrayList>(); Entry[] cpMap = ix.cpMap; assert(keys.length == cpMap.length); for (int i = 0; i < keys.length; i++) { -@@ -927,7 +927,7 @@ +@@ -930,7 +930,7 @@ } List part = parts.get(key); if (part == null) { @@ -92,37 +218,46 @@ } part.add(cpMap[i]); } +@@ -1137,7 +1137,7 @@ + void completeReferencesIn(Set cpRefs, boolean flattenSigs) { + cpRefs.remove(null); + for (ListIterator work = +- new ArrayList<>(cpRefs).listIterator(cpRefs.size()); ++ new ArrayList(cpRefs).listIterator(cpRefs.size()); + work.hasPrevious(); ) { + Entry e = work.previous(); + work.remove(); // pop stack diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Driver.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Driver.java ---- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Driver.java 2011-03-14 22:10:30.000000000 +0000 -+++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Driver.java 2011-03-16 22:41:33.034195793 +0000 +--- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Driver.java 2011-04-11 12:34:30.000000000 +0100 ++++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Driver.java 2011-04-13 15:10:03.606190699 +0100 @@ -59,7 +59,7 @@ ResourceBundle.getBundle("com.sun.java.util.jar.pack.DriverResource"); public static void main(String[] ava) throws IOException { -- ArrayList av = new ArrayList<>(Arrays.asList(ava)); -+ ArrayList av = new ArrayList(Arrays.asList(ava)); +- List av = new ArrayList<>(Arrays.asList(ava)); ++ List av = new ArrayList(Arrays.asList(ava)); boolean doPack = true; boolean doUnpack = false; -@@ -82,7 +82,7 @@ +@@ -84,7 +84,7 @@ } // Collect engine properties here: -- HashMap engProps = new HashMap<>(); -+ HashMap engProps = new HashMap(); +- Map engProps = new HashMap<>(); ++ Map engProps = new HashMap(); engProps.put(verboseProp, System.getProperty(verboseProp)); String optionMap; -@@ -96,7 +96,7 @@ +@@ -98,7 +98,7 @@ } // Collect argument properties here: -- HashMap avProps = new HashMap<>(); -+ HashMap avProps = new HashMap(); +- Map avProps = new HashMap<>(); ++ Map avProps = new HashMap(); try { for (;;) { String state = parseCommandOptions(av, optionMap, avProps); -@@ -515,7 +515,7 @@ +@@ -525,7 +525,7 @@ String resultString = null; // Convert options string into optLines dictionary. @@ -131,15 +266,27 @@ loadOptmap: for (String optline : options.split("\n")) { String[] words = optline.split("\\p{Space}+"); +diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/FixedList.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/FixedList.java +--- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/FixedList.java 2011-04-12 00:18:33.000000000 +0100 ++++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/FixedList.java 2011-04-13 15:10:03.606190699 +0100 +@@ -45,7 +45,7 @@ + private final ArrayList flist; + + protected FixedList(int capacity) { +- flist = new ArrayList<>(capacity); ++ flist = new ArrayList(capacity); + // initialize the list to null + for (int i = 0 ; i < capacity ; i++) { + flist.add(null); diff -Nru openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Package.java openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Package.java ---- openjdk-boot.orig/jdk/src/share/classes/com/sun/java/util/jar/pack/Package.java 2011-03-14 22:10:30.000000000 +0000 -+++ openjdk-boot/jdk/src/share/classes/com/sun/java/util/jar/pack/Package.java 2011-03-16 22:41:33.034195793 +0000 From ahughes at redhat.com Mon Apr 18 08:34:25 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 18 Apr 2011 16:34:25 +0100 Subject: IcedTea7 bumped to b130 - PLEASE TEST Message-ID: <20110418153425.GA29985@rivendell.middle-earth.co.uk> IcedTea7 is now using b130, the Developer Preview release of OpenJDK7. This is the one I intend to use in the release of IcedTea7 1.14. Please test and report bugs using IcedTea bugzilla: http://icedtea.classpath.org/bugzilla A release date will be announced once it feels close to being ready to ship. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From bugzilla-daemon at icedtea.classpath.org Mon Apr 18 08:36:20 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 18 Apr 2011 15:36:20 +0000 Subject: [Bug 411] Applet cannot load j2pkcs11 library In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=411 --- Comment #3 from Omair Majid 2011-04-18 15:36:19 --- The demos at https://www.e-contract.be/eid-applet-beta/ work for me using IcedTea-Web HEAD. There does seem to be an odd issue with loading the second applet (second in terms of loading order, so this happens with both the authentication and authorization tests). The first applet load and works. The second applet just shows a gray box. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dbhole at icedtea.classpath.org Mon Apr 18 08:37:57 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Mon, 18 Apr 2011 15:37:57 +0000 Subject: /hg/icedtea-web: 2 new changesets Message-ID: changeset 0d1874f9e7ff in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=0d1874f9e7ff author: Deepak Bhole date: Mon Apr 18 11:36:52 2011 -0400 Fixed RH691259: Midori sends a SIGSEGV with the IcedTea NP Plugin changeset bdb72bab9e9c in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=bdb72bab9e9c author: Deepak Bhole date: Mon Apr 18 11:37:52 2011 -0400 Fix applet rezising issue seen with some browsers (Midori) diffstat: ChangeLog | 14 ++++++++ plugin/icedteanp/IcedTeaNPPlugin.cc | 20 +++++++---- plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 26 +++++++++++++++- 3 files changed, 51 insertions(+), 9 deletions(-) diffs (101 lines): diff -r b4db997469a2 -r bdb72bab9e9c ChangeLog --- a/ChangeLog Thu Apr 14 21:41:32 2011 +0100 +++ b/ChangeLog Mon Apr 18 11:37:52 2011 -0400 @@ -1,3 +1,17 @@ +2011-04-18 Deepak Bhole + + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java + (PluginAppletPanelFactory::createPanel): Make the NetxPanel variable + final. Resize frame to work around problem whereby AppletViewerPanel + doesn't always set the right size initially. + +2011-04-18 Deepak Bhole + + RH691259: Midori sends a SIGSEGV with the IcedTea NP Plugin + * plugin/icedteanp/IcedTeaNPPlugin.cc (NP_Initialize): Rather than + returning immediately if already initialized, return after function tables + are reset. + 2010-04-11 Andrew John Hughes * configure.ac: diff -r b4db997469a2 -r bdb72bab9e9c plugin/icedteanp/IcedTeaNPPlugin.cc --- a/plugin/icedteanp/IcedTeaNPPlugin.cc Thu Apr 14 21:41:32 2011 +0100 +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc Mon Apr 18 11:37:52 2011 -0400 @@ -2009,14 +2009,12 @@ { PLUGIN_DEBUG ("NP_Initialize\n"); - if (initialized) - return NPERR_NO_ERROR; - else if ((browserTable == NULL) || (pluginTable == NULL)) - { - PLUGIN_ERROR ("Browser or plugin function table is NULL."); - - return NPERR_INVALID_FUNCTABLE_ERROR; - } + if ((browserTable == NULL) || (pluginTable == NULL)) + { + PLUGIN_ERROR ("Browser or plugin function table is NULL."); + + return NPERR_INVALID_FUNCTABLE_ERROR; + } // Ensure that the major version of the plugin API that the browser // expects is not more recent than the major version of the API that @@ -2123,6 +2121,12 @@ pluginTable->getvalue = NPP_GetValueProcPtr (ITNP_GetValue); #endif + // Re-setting the above tables multiple times is OK (as the + // browser may change its function locations). However + // anything beyond this point should only run once. + if (initialized) + return NPERR_NO_ERROR; + // Make sure the plugin data directory exists, creating it if // necessary. data_directory = g_strconcat (P_tmpdir, NULL); diff -r b4db997469a2 -r bdb72bab9e9c plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 14 21:41:32 2011 +0100 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Apr 18 11:37:52 2011 -0400 @@ -122,7 +122,7 @@ long handle, int x, int y, final URL doc, final Hashtable atts) { - NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { + final NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { public NetxPanel run() { NetxPanel panel = new NetxPanel(doc, atts, false); NetxPanel.debug("Using NetX panel"); @@ -171,6 +171,30 @@ PluginDebug.debug("Applet ", a.getClass(), " initialized"); streamhandler.write("instance " + identifier + " reference 0 initialized"); + /* AppletViewerPanel sometimes doesn't set size right initially. This + * causes the parent frame to be the default (10x10) size. + * + * Normally it goes unnoticed since browsers like Firefox make a resize + * call after init. However some browsers (e.g. Midori) don't. + * + * We therefore manually set the parent to the right size. + */ + try { + SwingUtilities.invokeAndWait(new Runnable() { + public void run() { + panel.getParent().setSize(Integer.valueOf(atts.get("width")), Integer.valueOf(atts.get("height"))); + } + }); + } catch (InvocationTargetException ite) { + // Not being able to resize is non-fatal + PluginDebug.debug("Unable to resize panel: "); + ite.printStackTrace(); + } catch (InterruptedException ie) { + // Not being able to resize is non-fatal + PluginDebug.debug("Unable to resize panel: "); + ie.printStackTrace(); + } + AppletSecurityContextManager.getSecurityContext(0).associateSrc(panel.getAppletClassLoader(), doc); AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, panel.getAppletClassLoader()); From andrew at icedtea.classpath.org Mon Apr 18 10:03:49 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Mon, 18 Apr 2011 17:03:49 +0000 Subject: /hg/icedtea: Remove unneeded import in Rhino patch. Message-ID: changeset 2cd959df7e7a in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=2cd959df7e7a author: Andrew John Hughes date: Mon Apr 18 18:03:43 2011 +0100 Remove unneeded import in Rhino patch. 2011-04-18 Andrew John Hughes * Makefile.am: (JDK_CHANGESET): Remove unneeded import in Rhino patch. (JDK_SHA256SUM): Likewise. diffstat: ChangeLog | 6 ++++++ Makefile.am | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diffs (34 lines): diff -r fef8fe66fdf5 -r 2cd959df7e7a ChangeLog --- a/ChangeLog Mon Apr 18 16:29:18 2011 +0100 +++ b/ChangeLog Mon Apr 18 18:03:43 2011 +0100 @@ -1,3 +1,9 @@ +2011-04-18 Andrew John Hughes + + * Makefile.am: + (JDK_CHANGESET): Remove unneeded import in Rhino patch. + (JDK_SHA256SUM): Likewise. + 2011-04-18 Andrew John Hughes * patches/icedtea-freetypeversion.patch: diff -r fef8fe66fdf5 -r 2cd959df7e7a Makefile.am --- a/Makefile.am Mon Apr 18 16:29:18 2011 +0100 +++ b/Makefile.am Mon Apr 18 18:03:43 2011 +0100 @@ -6,7 +6,7 @@ HOTSPOT_CHANGESET = bbfa41dad6d4 JAXP_CHANGESET = b6f201c0649a JAXWS_CHANGESET = 4c04de31900b -JDK_CHANGESET = d5404dcb1265 +JDK_CHANGESET = f6ac05b155d6 LANGTOOLS_CHANGESET = 4659da7bff78 OPENJDK_CHANGESET = d39d0c08731a @@ -14,7 +14,7 @@ HOTSPOT_SHA256SUM = bf4f93ae5782e4110ffc33fdc997c4c43f798eca9dff6db4784f8da51ff0f2c3 JAXP_SHA256SUM = a1a5c6b2671f83d4675f9ba25013c6a16a4cf4d1040fcd2ff4143c92bd5496a3 JAXWS_SHA256SUM = 8fe84a61142d579487bee98133fc26e57aedb97f781dc925ad3803aa40f5c061 -JDK_SHA256SUM = 78ff05e5128898830612dd117e7799f982663132d5fb518835cc5871a18d0427 +JDK_SHA256SUM = 564e9c9f7d6335d8fe221389893462dbb3daf4a20d9e75ffa37e9c8bbd7687be LANGTOOLS_SHA256SUM = 1df1bb1edd5f912405398c0024f8290f6a9030172dd1196c52e2c461769a1a07 OPENJDK_SHA256SUM = 937930cb6c3174f8bdbf3d0034832fbde539fd62591087f1d6fcec695ed20519 From ahughes at redhat.com Mon Apr 18 10:09:52 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Mon, 18 Apr 2011 18:09:52 +0100 Subject: [RFC]: Linkage Error fix. In-Reply-To: <4DABFA13.2040401@redhat.com> References: <107188343.372205.1302894608120.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110415195524.GA2598@redhat.com> <4DABFA13.2040401@redhat.com> Message-ID: <20110418170952.GC29985@rivendell.middle-earth.co.uk> On 09:45 Mon 18 Apr , Andrew Haley wrote: > On 15/04/11 20:55, Deepak Bhole wrote: > > > Did you look into how URLCloassLoader and others mitigate the problem? > > If I am not mistaken, all class load requests go through JNLPClassLoader, > > and synchronizing on each such call can get expensive. > > In 1.6 ClassLoader.loadClass() is a synchronized method anyway. > > There's something of a myth about the expense of synchronization that > isn't usually justified by actual measurements. It's usually only a > compareAndSwap, and there is little pain for uncontended cases. > Avoiding synchronization with more complex schemes may actually be > slower; you have to measure it. > Be correct first. Only then worry about performance. > > OTOH, if URLClassLoader is doing the same, we are not impacting the > > performance any further so it'd be okay. > > This is exactly how ClassLoader does it in 1.7. However, > ClassLoader's code is a bit more clear: > > protected Class loadClass(String name, boolean resolve) > throws ClassNotFoundException > { > synchronized (getClassLoadingLock(name)) { > > where > > protected Object getClassLoadingLock(String className) { > Object lock = this; > if (parallelLockMap != null) { > Object newLock = new Object(); > lock = parallelLockMap.putIfAbsent(className, newLock); > if (lock == null) { > lock = newLock; > } > } > return lock; > } > That change is due to: 4735126: (cl) ClassLoader.loadClass locks all instances in chain when delegating Summary: Added support for parallel-capable class loaders Reviewed-by: alanb > Andrew. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at icedtea.classpath.org Mon Apr 18 10:16:50 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Mon, 18 Apr 2011 17:16:50 +0000 Subject: /hg/release/icedtea-web-1.0: 2 new changesets Message-ID: changeset 4169f6296ed7 in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=4169f6296ed7 author: Deepak Bhole date: Mon Apr 18 11:36:52 2011 -0400 Fixed RH691259: Midori sends a SIGSEGV with the IcedTea NP Plugin changeset 2b7512af4dcc in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=2b7512af4dcc author: Deepak Bhole date: Mon Apr 18 13:16:39 2011 -0400 Fix applet rezising issue seen with some browsers (Midori) diffstat: ChangeLog | 14 ++++++++ plugin/icedteanp/IcedTeaNPPlugin.cc | 20 +++++++---- plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 26 +++++++++++++++- 3 files changed, 51 insertions(+), 9 deletions(-) diffs (101 lines): diff -r 218e20b249b8 -r 2b7512af4dcc ChangeLog --- a/ChangeLog Thu Apr 07 18:06:40 2011 -0400 +++ b/ChangeLog Mon Apr 18 13:16:39 2011 -0400 @@ -1,3 +1,17 @@ +2011-04-18 Deepak Bhole + + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java + (PluginAppletPanelFactory::createPanel): Make the NetxPanel variable + final. Resize frame to work around problem whereby AppletViewerPanel + doesn't always set the right size initially. + +2011-04-18 Deepak Bhole + + RH691259: Midori sends a SIGSEGV with the IcedTea NP Plugin + * plugin/icedteanp/IcedTeaNPPlugin.cc (NP_Initialize): Rather than + returning immediately if already initialized, return after function tables + are reset. + 2011-04-07 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java diff -r 218e20b249b8 -r 2b7512af4dcc plugin/icedteanp/IcedTeaNPPlugin.cc --- a/plugin/icedteanp/IcedTeaNPPlugin.cc Thu Apr 07 18:06:40 2011 -0400 +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc Mon Apr 18 13:16:39 2011 -0400 @@ -2005,14 +2005,12 @@ { PLUGIN_DEBUG ("NP_Initialize\n"); - if (initialized) - return NPERR_NO_ERROR; - else if ((browserTable == NULL) || (pluginTable == NULL)) - { - PLUGIN_ERROR ("Browser or plugin function table is NULL."); - - return NPERR_INVALID_FUNCTABLE_ERROR; - } + if ((browserTable == NULL) || (pluginTable == NULL)) + { + PLUGIN_ERROR ("Browser or plugin function table is NULL."); + + return NPERR_INVALID_FUNCTABLE_ERROR; + } // Ensure that the major version of the plugin API that the browser // expects is not more recent than the major version of the API that @@ -2119,6 +2117,12 @@ pluginTable->getvalue = NPP_GetValueProcPtr (ITNP_GetValue); #endif + // Re-setting the above tables multiple times is OK (as the + // browser may change its function locations). However + // anything beyond this point should only run once. + if (initialized) + return NPERR_NO_ERROR; + // Make sure the plugin data directory exists, creating it if // necessary. data_directory = g_strconcat (P_tmpdir, NULL); diff -r 218e20b249b8 -r 2b7512af4dcc plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 07 18:06:40 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Apr 18 13:16:39 2011 -0400 @@ -126,7 +126,7 @@ long handle, int x, int y, final URL doc, final Hashtable atts) { - AppletViewerPanel panel = AccessController.doPrivileged(new PrivilegedAction() { + final AppletViewerPanel panel = AccessController.doPrivileged(new PrivilegedAction() { public AppletViewerPanel run() { try { AppletViewerPanel panel = new NetxPanel(doc, atts, false); @@ -192,6 +192,30 @@ PluginDebug.debug("Applet " + a.getClass() + " initialized"); streamhandler.write("instance " + identifier + " reference 0 initialized"); + /* AppletViewerPanel sometimes doesn't set size right initially. This + * causes the parent frame to be the default (10x10) size. + * + * Normally it goes unnoticed since browsers like Firefox make a resize + * call after init. However some browsers (e.g. Midori) don't. + * + * We therefore manually set the parent to the right size. + */ + try { + SwingUtilities.invokeAndWait(new Runnable() { + public void run() { + panel.getParent().setSize(Integer.valueOf(atts.get("width")), Integer.valueOf(atts.get("height"))); + } + }); + } catch (InvocationTargetException ite) { + // Not being able to resize is non-fatal + PluginDebug.debug("Unable to resize panel: "); + ite.printStackTrace(); + } catch (InterruptedException ie) { + // Not being able to resize is non-fatal + PluginDebug.debug("Unable to resize panel: "); + ie.printStackTrace(); + } + AppletSecurityContextManager.getSecurityContext(0).associateSrc(((NetxPanel) panel).getAppletClassLoader(), doc); AppletSecurityContextManager.getSecurityContext(0).associateInstance(identifier, ((NetxPanel) panel).getAppletClassLoader()); From dbhole at redhat.com Mon Apr 18 10:17:24 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 18 Apr 2011 13:17:24 -0400 Subject: [icedtea-web] RFC: Patches to make the plugin work with Midori In-Reply-To: <4DA8D5CB.6080806@redhat.com> References: <20110415225734.GB2598@redhat.com> <20110415225819.GC2598@redhat.com> <4DA8D5CB.6080806@redhat.com> Message-ID: <20110418171724.GB12195@redhat.com> * Omair Majid [2011-04-15 19:33]: > On 04/15/2011 06:58 PM, Deepak Bhole wrote: > > > >>> > > Both patches look good to me. > Pushed to both branches. Thanks! Cheers, Deepak > Cheers, > Omair From bugzilla-daemon at icedtea.classpath.org Mon Apr 18 10:34:16 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 18 Apr 2011 17:34:16 +0000 Subject: [Bug 676] milliseconds bug in java.sql.Timestamp In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=676 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gnu_andrew at member.fsf.org --- Comment #7 from Andrew John Hughes 2011-04-18 17:34:16 --- See http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-April/006625.html -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From pcpa at mandriva.com.br Mon Apr 18 10:44:43 2011 From: pcpa at mandriva.com.br (Paulo =?iso-8859-1?Q?C=E9sar_Pereira_de_Andrade?=) Date: Mon, 18 Apr 2011 14:44:43 -0300 Subject: About packaging up to date java-1.6.0-opendk / icedtea6-1.10* / icedtea-web-1* Message-ID: Hi, Currently I am stuck at packaging icedtea 1.9.7 and openjdk b20. I should note that most times I just rip/synch to fedora rpm spec, and that I am not a java advocate/programmer, and basically only started maintaining the package in mandriva to have a working java plugin, and the only test case I usually do is the jmol plugin, used by another package I maintain. I added recently a sample spec file to http://icedtea.classpath.org/bugzilla/attachment.cgi?id=509 the sample spec actually did not install files under the previous layout, but did not work anyway. Later I found that there is/was http://pkgs.fedoraproject.org/gitweb/?p=icedtea-web.git but that did not work either. In both tests I used openjdk-6-src-b22-28_feb_2011.tar.gz and icedtea6-1.10.1.tar.gz, and the icedtea-web tested were first a snapshot, icedtea-web-24f034f372e4.tar.bz2 and later I tried icedtea-web-1.0.2.tar.gz from what I could get from the fedora git. Drops were the previous ones or if the build would attempt to download it, I would update the rpm source to use files from http://icedtea.classpath.org/download/drops Problem is that I cannot see any problems when running either ICEDTEAPLUGIN_DEBUG=1 firefox or ICEDTEAPLUGIN_DEBUG=1 chromium-browser but I just see a large amount of what appears to be ok log messages, but the plugin never starts. Browsers tested are: $ rpm -q firefox chromium-browser-unstable firefox-4.0-1-mdv2011.0.x86_64 chromium-browser-unstable-12.0.733.0-1-mdv2011.0.x86_64 Sorry for the long email, but I think it is better to give some feedback. Thanks, Paulo From andrew at icedtea.classpath.org Mon Apr 18 10:44:45 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Mon, 18 Apr 2011 17:44:45 +0000 Subject: /hg/icedtea-web: Switch to explicit locks and condition queues i... Message-ID: changeset c083edb1ce29 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=c083edb1ce29 author: Andrew John Hughes date: Mon Apr 18 18:44:40 2011 +0100 Switch to explicit locks and condition queues in PluginAppletViewer 2010-04-14 Andrew John Hughes * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java, (PluginAppletPanelFactory.createPanel(PluginStreamHandler, int,long,int,int,URL,Hashtable)): Remove duplication of wait for panel.isAlive(). (PluginAppletViewer.panelLock): New lock used to track panel creation. (PluginAppletViewer.panelLive): Condition queue for panel creation. (PluginAppletViewer.appletsLock): New lock used to track additions to the applets map. (PluginAppletViewer.appletAdded): Condition queue for applet addition. (PluginAppletViewer.statusLock): New lock for status changes. (PluginAppletViewer.initComplete): Condition queue for initialisation completion. (PluginAppletViewer.framePanel(int,long,NetxPanel)): Replace synchronized block with use of appletsLock and notification on appletAdded condition queue. (AppletEventListener.appletStateChanged(AppletEvent)): Signal the panelLive condition queue that the panel is live. (PluginAppletViewer.handleMessage(int,int,String)): Wait on appletAdded condition queue for applet to be added to the applets map. (PluginAppletViewer.updateStatus(Int,PAV_INIT_STATUS)): Signal when a status change occurs using the initComplete condition queue. (PluginAppletViewer.waitForAppletInit(NetxPanel)): Wait on the panelLive condition queue until the panel is created. (PluginAppletViewer.handleMessage(int,String)): Wait on the initComplete condition queue until initialisation is complete. Wait on the panelLive signal until panel is created. (waitTillTimeout(ReentrantLock,Condition,long)): Convert to use ReentrantLock and Condition. Add assertion to check the lock is held. Avoid conversion between milliseconds and nanoseconds. diffstat: ChangeLog | 33 +++ plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 142 +++++++------- 2 files changed, 107 insertions(+), 68 deletions(-) diffs (336 lines): diff -r bdb72bab9e9c -r c083edb1ce29 ChangeLog --- a/ChangeLog Mon Apr 18 11:37:52 2011 -0400 +++ b/ChangeLog Mon Apr 18 18:44:40 2011 +0100 @@ -1,3 +1,36 @@ +2010-04-14 Andrew John Hughes + + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java, + (PluginAppletPanelFactory.createPanel(PluginStreamHandler, + int,long,int,int,URL,Hashtable)): Remove duplication of wait + for panel.isAlive(). + (PluginAppletViewer.panelLock): New lock used to track panel + creation. + (PluginAppletViewer.panelLive): Condition queue for panel creation. + (PluginAppletViewer.appletsLock): New lock used to track additions + to the applets map. + (PluginAppletViewer.appletAdded): Condition queue for applet addition. + (PluginAppletViewer.statusLock): New lock for status changes. + (PluginAppletViewer.initComplete): Condition queue for initialisation + completion. + (PluginAppletViewer.framePanel(int,long,NetxPanel)): + Replace synchronized block with use of appletsLock and notification + on appletAdded condition queue. + (AppletEventListener.appletStateChanged(AppletEvent)): Signal the + panelLive condition queue that the panel is live. + (PluginAppletViewer.handleMessage(int,int,String)): Wait on appletAdded + condition queue for applet to be added to the applets map. + (PluginAppletViewer.updateStatus(Int,PAV_INIT_STATUS)): Signal when a + status change occurs using the initComplete condition queue. + (PluginAppletViewer.waitForAppletInit(NetxPanel)): Wait on the panelLive + condition queue until the panel is created. + (PluginAppletViewer.handleMessage(int,String)): Wait on the initComplete + condition queue until initialisation is complete. Wait on the panelLive + signal until panel is created. + (waitTillTimeout(ReentrantLock,Condition,long)): Convert to use + ReentrantLock and Condition. Add assertion to check the lock is held. + Avoid conversion between milliseconds and nanoseconds. + 2011-04-18 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java diff -r bdb72bab9e9c -r c083edb1ce29 plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Apr 18 11:37:52 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Mon Apr 18 18:44:40 2011 +0100 @@ -97,8 +97,13 @@ import java.util.Iterator; import java.util.Map; import java.util.Vector; + import java.util.concurrent.ConcurrentHashMap; import java.util.concurrent.ConcurrentMap; +import java.util.concurrent.TimeUnit; + +import java.util.concurrent.locks.Condition; +import java.util.concurrent.locks.ReentrantLock; import javax.swing.SwingUtilities; @@ -139,25 +144,7 @@ // Start the applet initEventQueue(panel); - // Wait for panel to come alive - // Wait implemented the long way so that - // PluginAppletViewer.waitTillTimeout() needn't be exposed. - long maxTimeToSleep = PluginAppletViewer.APPLET_TIMEOUT/1000000; // ns -> ms - - synchronized(panel) { - while (!panel.isAlive() && maxTimeToSleep > 0) { - long sleepStart = System.nanoTime(); - - try { - panel.wait(maxTimeToSleep); - } catch (InterruptedException e) {} // Just loop back - - maxTimeToSleep -= (System.nanoTime() - sleepStart)/1000000; // ns -> ms - } - } - // Wait for the panel to initialize - // (happens in a separate thread) PluginAppletViewer.waitForAppletInit(panel); Applet a = panel.getApplet(); @@ -287,12 +274,17 @@ * The panel in which the applet is being displayed. */ private NetxPanel panel; - + static final ReentrantLock panelLock = new ReentrantLock(); + // CONDITION PREDICATE: panel.isAlive() + static final Condition panelLive = panelLock.newCondition(); private int identifier; // Instance identifier -> PluginAppletViewer object. private static ConcurrentMap applets = new ConcurrentHashMap(); + private static final ReentrantLock appletsLock = new ReentrantLock(); + // CONDITION PREDICATE: !applets.containsKey(identifier) + private static final Condition appletAdded = appletsLock.newCondition(); private static PluginStreamHandler streamhandler; @@ -300,6 +292,9 @@ private static ConcurrentMap status = new ConcurrentHashMap(); + private static final ReentrantLock statusLock = new ReentrantLock(); + // CONDITION PREDICATE: !status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) + private static final Condition initComplete = statusLock.newCondition(); private WindowListener windowEventListener = null; private AppletEventListener appletEventListener = null; @@ -333,11 +328,10 @@ appletFrame.appletEventListener = new AppletEventListener(appletFrame, appletFrame); panel.addAppletListener(appletFrame.appletEventListener); - - synchronized(applets) { - applets.put(identifier, appletFrame); - applets.notifyAll(); - } + appletsLock.lock(); + applets.put(identifier, appletFrame); + appletAdded.signalAll(); + appletsLock.unlock(); PluginDebug.debug(panel, " framed"); } @@ -388,9 +382,9 @@ public void appletStateChanged(AppletEvent evt) { AppletPanel src = (AppletPanel) evt.getSource(); - synchronized (src) { - src.notifyAll(); - } + panelLock.lock(); + panelLive.signalAll(); + panelLock.unlock(); switch (evt.getID()) { case AppletPanel.APPLET_RESIZE: { @@ -484,12 +478,17 @@ new URL(documentBase)); long maxTimeToSleep = APPLET_TIMEOUT; - synchronized(applets) { + appletsLock.lock(); + try { while (!applets.containsKey(identifier) && maxTimeToSleep > 0) { // Map is populated only by reFrame - maxTimeToSleep -= waitTillTimeout(applets, maxTimeToSleep); + maxTimeToSleep -= waitTillTimeout(appletsLock, appletAdded, + maxTimeToSleep); } } + finally { + appletsLock.unlock(); + } // If wait exceeded maxWait, we timed out. Throw an exception if (maxTimeToSleep <= 0) @@ -576,11 +575,11 @@ } // Else set to given status - - synchronized(status) { - status.put(identifier, newStatus); - status.notifyAll(); - } + + statusLock.lock(); + status.put(identifier, newStatus); + initComplete.signalAll(); + statusLock.unlock(); return prev; } @@ -634,7 +633,7 @@ /** * Function to block until applet initialization is complete. - * + * * This function will return if the wait is longer than {@link #APPLET_TIMEOUT} * * @param panel the instance to wait for. @@ -644,14 +643,18 @@ // Wait till initialization finishes long maxTimeToSleep = APPLET_TIMEOUT; - synchronized(panel) { + panelLock.lock(); + try { while (panel.getApplet() == null && panel.isAlive() && maxTimeToSleep > 0) { PluginDebug.debug("Waiting for applet panel ", panel, " to initialize..."); - maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); + maxTimeToSleep -= waitTillTimeout(panelLock, panelLive, maxTimeToSleep); } } + finally { + panelLock.unlock(); + } PluginDebug.debug("Applet panel ", panel, " initialized"); } @@ -661,12 +664,17 @@ // Wait for panel to come alive long maxTimeToSleep = APPLET_TIMEOUT; - synchronized(status) { + statusLock.lock(); + try { while (!status.get(identifier).equals(PAV_INIT_STATUS.INIT_COMPLETE) && maxTimeToSleep > 0) { - maxTimeToSleep -= waitTillTimeout(status, maxTimeToSleep); + maxTimeToSleep -= waitTillTimeout(statusLock, initComplete, + maxTimeToSleep); } } + finally { + statusLock.unlock(); + } // 0 => width, 1=> width_value, 2 => height, 3=> height_value String[] dimMsg = message.split(" "); @@ -715,21 +723,18 @@ // FIXME: how do we determine what security context this // object should belong to? Object o; - + // First, wait for panel to instantiate - int waited = 0; - while (panel == null && waited < APPLET_TIMEOUT) { - try { - Thread.sleep(50); - waited += 50; - } catch (InterruptedException ie) {} // discard, loop back - } - // Next, wait for panel to come alive long maxTimeToSleep = APPLET_TIMEOUT; - synchronized(panel) { - while (!panel.isAlive()) - maxTimeToSleep -= waitTillTimeout(panel, maxTimeToSleep); + panelLock.lock(); + try { + while (panel == null || !panel.isAlive()) + maxTimeToSleep -= waitTillTimeout(panelLock, panelLive, + maxTimeToSleep); + } + finally { + panelLock.unlock(); } // Wait for the panel to initialize @@ -1394,7 +1399,7 @@ /** * Decodes the string (converts html escapes into proper characters) - * + * * @param toDecode The string to decode * @return The decoded string */ @@ -1409,7 +1414,7 @@ return toDecode; } - + /** * System parameters. */ @@ -1595,7 +1600,7 @@ public void run() { ClassLoader cl = p.applet.getClass().getClassLoader(); - // Since we want to deal with JNLPClassLoader, extract it if this + // Since we want to deal with JNLPClassLoader, extract it if this // is a codebase loader if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); @@ -2084,34 +2089,35 @@ } /** - * Waits on a given object until timeout. - * + * Waits on a given condition queue until timeout. + * * This function assumes that the monitor lock has already been * acquired by the caller. - * - * If the given object is null, this function returns immediately. - * - * @param obj The object to wait on + * + * If the given lock is null, this function returns immediately. + * + * @param lock the lock that must be held when this method is called. + * @param cond the condition queue on which to wait for notifications. * @param timeout The maximum time to wait (nanoseconds) * @return Approximate time spent sleeping (not guaranteed to be perfect) */ - public static long waitTillTimeout(Object obj, long timeout) { + public static long waitTillTimeout(ReentrantLock lock, Condition cond, + long timeout) { // Can't wait on null. Return 0 indicating no wait happened. - if (obj == null) + if (lock == null) return 0; - + + assert lock.isHeldByCurrentThread(); + // Record when we started sleeping long sleepStart = 0L; - // Convert timeout to ms since wait() takes ms - timeout = timeout >= 1000000 ? timeout/1000000 : 1; - try { sleepStart = System.nanoTime(); - obj.wait(timeout); + cond.await(timeout, TimeUnit.NANOSECONDS); } catch (InterruptedException ie) {} // Discarded, time to return - + // Return the difference return System.nanoTime() - sleepStart; } From dbhole at redhat.com Mon Apr 18 10:48:59 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 18 Apr 2011 13:48:59 -0400 Subject: [RFC]: Linkage Error fix. In-Reply-To: <20110418170952.GC29985@rivendell.middle-earth.co.uk> References: <107188343.372205.1302894608120.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110415195524.GA2598@redhat.com> <4DABFA13.2040401@redhat.com> <20110418170952.GC29985@rivendell.middle-earth.co.uk> Message-ID: <20110418174859.GC12195@redhat.com> * Dr Andrew John Hughes [2011-04-18 13:10]: > On 09:45 Mon 18 Apr , Andrew Haley wrote: > > On 15/04/11 20:55, Deepak Bhole wrote: > > > > > Did you look into how URLCloassLoader and others mitigate the problem? > > > If I am not mistaken, all class load requests go through JNLPClassLoader, > > > and synchronizing on each such call can get expensive. > > > > In 1.6 ClassLoader.loadClass() is a synchronized method anyway. > > > > There's something of a myth about the expense of synchronization that > > isn't usually justified by actual measurements. It's usually only a > > compareAndSwap, and there is little pain for uncontended cases. > > Avoiding synchronization with more complex schemes may actually be > > slower; you have to measure it. > > > > Be correct first. Only then worry about performance. Replying here for this message: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013664.html The new patch synchronizes all of loadClass. I am against this approach with the current design. The latter part of loadClass() connects to remote sites to download additional jars. Networks are unreliable and synchronizing a critical method like loadClass knowing it can get delayed on network is a bad idea IMO. That is one of the reasons I suggested studying how URLClassLoader does it.. it too has to deal with remote connectivity for loading, so it probably has a cleaner solution for this. Cheers, Deepak From aph at redhat.com Mon Apr 18 11:01:04 2011 From: aph at redhat.com (Andrew Haley) Date: Mon, 18 Apr 2011 19:01:04 +0100 Subject: [RFC]: Linkage Error fix. In-Reply-To: <20110418174859.GC12195@redhat.com> References: <107188343.372205.1302894608120.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110415195524.GA2598@redhat.com> <4DABFA13.2040401@redhat.com> <20110418170952.GC29985@rivendell.middle-earth.co.uk> <20110418174859.GC12195@redhat.com> Message-ID: <4DAC7C60.3020307@redhat.com> On 04/18/2011 06:48 PM, Deepak Bhole wrote: > * Dr Andrew John Hughes [2011-04-18 13:10]: >> On 09:45 Mon 18 Apr , Andrew Haley wrote: >>> On 15/04/11 20:55, Deepak Bhole wrote: >>> >>>> Did you look into how URLCloassLoader and others mitigate the problem? >>>> If I am not mistaken, all class load requests go through JNLPClassLoader, >>>> and synchronizing on each such call can get expensive. >>> >>> In 1.6 ClassLoader.loadClass() is a synchronized method anyway. >>> >>> There's something of a myth about the expense of synchronization that >>> isn't usually justified by actual measurements. It's usually only a >>> compareAndSwap, and there is little pain for uncontended cases. >>> Avoiding synchronization with more complex schemes may actually be >>> slower; you have to measure it. >>> >> >> Be correct first. Only then worry about performance. > > Replying here for this message: > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013664.html > > The new patch synchronizes all of loadClass. I am against this > approach with the current design. > > The latter part of loadClass() connects to remote sites to download > additional jars. Networks are unreliable and synchronizing a critical > method like loadClass knowing it can get delayed on network is a bad > idea IMO. > > That is one of the reasons I suggested studying how URLClassLoader does > it.. it too has to deal with remote connectivity for loading, so it > probably has a cleaner solution for this. You can call getResource, which doesn't need locking, and then call defineClass(name, resource) only once you have the bytes. Andrew. From dbhole at redhat.com Mon Apr 18 11:59:55 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 18 Apr 2011 14:59:55 -0400 Subject: [RFC]: Linkage Error fix. In-Reply-To: <4DAC7C60.3020307@redhat.com> References: <107188343.372205.1302894608120.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110415195524.GA2598@redhat.com> <4DABFA13.2040401@redhat.com> <20110418170952.GC29985@rivendell.middle-earth.co.uk> <20110418174859.GC12195@redhat.com> <4DAC7C60.3020307@redhat.com> Message-ID: <20110418185955.GD12195@redhat.com> * Andrew Haley [2011-04-18 14:01]: > On 04/18/2011 06:48 PM, Deepak Bhole wrote: > > * Dr Andrew John Hughes [2011-04-18 13:10]: > >> On 09:45 Mon 18 Apr , Andrew Haley wrote: > >>> On 15/04/11 20:55, Deepak Bhole wrote: > >>> > >>>> Did you look into how URLCloassLoader and others mitigate the problem? > >>>> If I am not mistaken, all class load requests go through JNLPClassLoader, > >>>> and synchronizing on each such call can get expensive. > >>> > >>> In 1.6 ClassLoader.loadClass() is a synchronized method anyway. > >>> > >>> There's something of a myth about the expense of synchronization that > >>> isn't usually justified by actual measurements. It's usually only a > >>> compareAndSwap, and there is little pain for uncontended cases. > >>> Avoiding synchronization with more complex schemes may actually be > >>> slower; you have to measure it. > >>> > >> > >> Be correct first. Only then worry about performance. > > > > Replying here for this message: > > > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013664.html > > > > The new patch synchronizes all of loadClass. I am against this > > approach with the current design. > > > > The latter part of loadClass() connects to remote sites to download > > additional jars. Networks are unreliable and synchronizing a critical > > method like loadClass knowing it can get delayed on network is a bad > > idea IMO. > > > > That is one of the reasons I suggested studying how URLClassLoader does > > it.. it too has to deal with remote connectivity for loading, so it > > probably has a cleaner solution for this. > > You can call getResource, which doesn't need locking, and then call > defineClass(name, resource) only once you have the bytes. > Just finished studying URLClassLoader. Interestingly enough, it ultimately blocks class loading on network access too. ClassLoader.loadClass() is synchronized. If a class is not loaded, it calls findClass() which is overloaded by URLClassLoader. URLClassLoader.findClass() ultimately calls JarLoader.ensureOpen() if the class is not found. ensureOpen() opens a network connection (confirmed by checking local server load) while in a synchronized block. Making loadClass() will therefore be no worse than what URLClassLoader does. I am therefore okay with the patch in: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013664.html The security rewrite will inevitably change JNLPClassLoader significantly, and I will re-assess this then to see if we can do something better. Cheers, Deepak From dbhole at redhat.com Mon Apr 18 12:03:27 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Mon, 18 Apr 2011 15:03:27 -0400 Subject: [RFC]: Linkage Error fix. In-Reply-To: <20110418185955.GD12195@redhat.com> References: <107188343.372205.1302894608120.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <316005009.372644.1302896502982.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110415195524.GA2598@redhat.com> <4DABFA13.2040401@redhat.com> <20110418170952.GC29985@rivendell.middle-earth.co.uk> <20110418174859.GC12195@redhat.com> <4DAC7C60.3020307@redhat.com> <20110418185955.GD12195@redhat.com> Message-ID: <20110418190327.GA25036@redhat.com> Not enough coffee :/ * Deepak Bhole [2011-04-18 15:01]: > (confirmed by checking local server load) while in a synchronized block. > s/server load/server log > Making loadClass() will therefore be no worse than what URLClassLoader s/Making loadClass()/Making loadClass() synchronized Deepak > does. I am therefore okay with the patch in: > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013664.html > > The security rewrite will inevitably change JNLPClassLoader > significantly, and I will re-assess this then to see if we can do > something better. > > Cheers, > Deepak > From asu at redhat.com Mon Apr 18 12:06:35 2011 From: asu at redhat.com (Andrew Su) Date: Mon, 18 Apr 2011 15:06:35 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <4DAC48AC.8040000@redhat.com> Message-ID: <2014503727.41605.1303153595902.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Omair Majid" > To: "Andrew Su" > Cc: "Denis Lila" , "IcedTea" > Sent: Monday, April 18, 2011 10:20:28 AM > Subject: Re: [RFC][Icedtea-web]: Changed how cache works. > On 04/16/2011 07:39 PM, Andrew Su wrote: > > > > > >>> > >>>>> + public synchronized boolean addEntry(String identifier, > >>>>> String path) { > >>> > >>>>> + public synchronized boolean removeEntry(String key) { > >>> > >>>>> + public synchronized boolean updateEntry(String oldKey) { > >>> > >>> I would have been happier with all these methods taking > >>> identifiers or keys. As such, there is on way to add an entry and > >>> then remove it (as you wouldnt know the key for it). > > I've changed it to take a key for addEntry instead of identifier. > > I dont think this is the right way. Now the implementation knowledge > is > spread across multiple classes. If you change the key in > makeNewCacheFile, CacheLRUWrapper will need need to be updated too :( > Perhaps a fix would be to create a method like generateKey(Sting path) > in CacheLRUWrapper? The key returned by this method would be used in > addEntry. I've added generateKey to CacheLRUWrapper. > > >>> > >>> Have you tested this while offline? I am afraid that this might > >>> break running jnlp applications offline. > > If by testing this offline you mean run it using a jnlp file, let it > > cache, then run jnlp file while disconnected from the internet and > > still be able to launch it? Then yes, however it fails to launch the > > cached item. This actually happens with HEAD without my patch too. > > (Running jnlp file while connected works) > > > > Ugh. That sucks :( I know this was working in Feburary (my demos at > FOSDEM were running offline). I wonder if I accidentally broke it. It's ok, nothing we can't fix ;) > > >>> > >>> Everything else looks fine to me. > >>> > > I've made some minor changes, notably adding an entry for compressed > > files, since when files are compressed, comparison with extracted > > file's size against the recorded size will definitely be different > > (so I avoid this check, have let isCurrent handle the rest by > > checking last-modified). > > > > Are the markCompressed/isCompressed methods used anywhere? If not, > could > you please make that a separate patch? Yes, I've added the use of isCompressed in CacheEntry.isCached(). Reason being that if the item was extracted, the content-length reported by the connection would differ from actual file size, thus forcing it to download without actually checking the modified time. > > > Thanks for reviewing my patches! > > > > No problem! > Is the patch okay now? Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110418_cache_vXX.patch Type: text/x-patch Size: 32347 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110418/954dd3dc/20110418_cache_vXX.patch From dlila at icedtea.classpath.org Mon Apr 18 12:09:54 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Mon, 18 Apr 2011 19:09:54 +0000 Subject: /hg/icedtea-web: Fix concurrent classloading problem in JNLPClas... Message-ID: changeset 37f99d9fbdeb in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=37f99d9fbdeb author: Denis Lila date: Mon Apr 18 15:13:23 2011 -0400 Fix concurrent classloading problem in JNLPClassLoader.loadClass. diffstat: ChangeLog | 8 ++++++++ netx/net/sourceforge/jnlp/Launcher.java | 1 - netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java | 6 ++++-- 3 files changed, 12 insertions(+), 3 deletions(-) diffs (63 lines): diff -r c083edb1ce29 -r 37f99d9fbdeb ChangeLog --- a/ChangeLog Mon Apr 18 18:44:40 2011 +0100 +++ b/ChangeLog Mon Apr 18 15:13:23 2011 -0400 @@ -1,3 +1,11 @@ +2011-04-18 Denis Lila + + * netx/net/sourceforge/jnlp/Launcher.java: + Remove unused import. + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: + Add annotation to suppress warning. + (loadClass): Make synchronized. + 2010-04-14 Andrew John Hughes * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java, diff -r c083edb1ce29 -r 37f99d9fbdeb netx/net/sourceforge/jnlp/Launcher.java --- a/netx/net/sourceforge/jnlp/Launcher.java Mon Apr 18 18:44:40 2011 +0100 +++ b/netx/net/sourceforge/jnlp/Launcher.java Mon Apr 18 15:13:23 2011 -0400 @@ -31,7 +31,6 @@ import java.util.jar.JarFile; import net.sourceforge.jnlp.cache.CacheUtil; -import net.sourceforge.jnlp.cache.ResourceTracker; import net.sourceforge.jnlp.cache.UpdatePolicy; import net.sourceforge.jnlp.runtime.AppThreadGroup; import net.sourceforge.jnlp.runtime.AppletInstance; diff -r c083edb1ce29 -r 37f99d9fbdeb netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Mon Apr 18 18:44:40 2011 +0100 +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Mon Apr 18 15:13:23 2011 -0400 @@ -650,6 +650,7 @@ protected void activateJars(final List jars) { PrivilegedAction activate = new PrivilegedAction() { + @SuppressWarnings("deprecation") public Void run() { // transfer the Jars waitForJars(jars); @@ -983,7 +984,7 @@ * classloader, or one of the classloaders for the JNLP file's * extensions. */ - public Class loadClass(String name) throws ClassNotFoundException { + public synchronized Class loadClass(String name) throws ClassNotFoundException { Class result = findLoadedClassAll(name); @@ -1003,7 +1004,7 @@ // validPackage(name); // search this and the extension loaders - if (result == null) + if (result == null) { try { result = loadClassExt(name); } catch (ClassNotFoundException cnfe) { @@ -1060,6 +1061,7 @@ } } } + } if (result == null) { throw new ClassNotFoundException(name); From omajid at redhat.com Mon Apr 18 12:23:43 2011 From: omajid at redhat.com (Omair Majid) Date: Mon, 18 Apr 2011 15:23:43 -0400 Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <2014503727.41605.1303153595902.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <2014503727.41605.1303153595902.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4DAC8FBF.2080506@redhat.com> On 04/18/2011 03:06 PM, Andrew Su wrote: >> >> Are the markCompressed/isCompressed methods used anywhere? If not, >> could you please make that a separate patch? > > Yes, I've added the use of isCompressed in CacheEntry.isCached(). > Reason being that if the item was extracted, the content-length reported > by the connection would differ from actual file size, thus forcing it to > download without actually checking the modified time. > That is a problem, but it seems orthogonal to the rest of the patch. I am not sure simply ignoring the content-length for compressed files is the best thing to do. We wont be able to detect changes in file size. Perhaps we should be storing uncompressed size instead? > > Is the patch okay now? > I would have preferred it if the isCompressed() and related stuff were in a separate patch - the rest of the stuff looks ok to me. Cheers, Omair From asu at redhat.com Mon Apr 18 12:41:49 2011 From: asu at redhat.com (Andrew Su) Date: Mon, 18 Apr 2011 15:41:49 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <4DAC8FBF.2080506@redhat.com> Message-ID: <1486595406.42463.1303155709627.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Omair Majid" > To: "Andrew Su" > Cc: "Denis Lila" , "IcedTea" > Sent: Monday, April 18, 2011 3:23:43 PM > Subject: Re: [RFC][Icedtea-web]: Changed how cache works. > On 04/18/2011 03:06 PM, Andrew Su wrote: > >> > >> Are the markCompressed/isCompressed methods used anywhere? If not, > >> could you please make that a separate patch? > > > > Yes, I've added the use of isCompressed in CacheEntry.isCached(). > > Reason being that if the item was extracted, the content-length > > reported > > by the connection would differ from actual file size, thus forcing > > it to > > download without actually checking the modified time. > > > > That is a problem, but it seems orthogonal to the rest of the patch. I > am not sure simply ignoring the content-length for compressed files is > the best thing to do. We wont be able to detect changes in file size. > Perhaps we should be storing uncompressed size instead? We can discuss a more on this after this gets in. > > > > > Is the patch okay now? > > > > I would have preferred it if the isCompressed() and related stuff were > in a separate patch - the rest of the stuff looks ok to me. Ok to push after removing the checks for compression? Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110418_cache_vXX2.patch Type: text/x-patch Size: 31185 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110418/3f15cdc3/20110418_cache_vXX2.patch From dlila at redhat.com Mon Apr 18 13:49:04 2011 From: dlila at redhat.com (Denis Lila) Date: Mon, 18 Apr 2011 16:49:04 -0400 (EDT) Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1486595406.42463.1303155709627.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1913176682.527072.1303159744830.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Ok to push after removing the checks for compression? I'm ok with it. But I will say that I am still uncomfortable with the entries of recently_used being (timeMillis, path) instead of the other way around. Also, is it true that every cached file is in it's own numbered directory (i.e. each directory contains exactly one cached file)? makeNewCacheFile only creates a cache file for the given URL if the directory does not exist. In other words, if the cache is empty, and I use an app that caches file1.jar and file2.jar, doing "ls ~/.icedtea/cache" will give 0 1 recently_used and the only file in directory "0" is file1.jar, and the only file in directory "1" is file2.jar. This seems kind of... redundant to me. Anyway, the above are not correctness problems, and if desired we can fix them later. I think this patch should go in. Regards, Denis. ----- Original Message ----- > ----- Original Message ----- > > From: "Omair Majid" > > To: "Andrew Su" > > Cc: "Denis Lila" , "IcedTea" > > > > Sent: Monday, April 18, 2011 3:23:43 PM > > Subject: Re: [RFC][Icedtea-web]: Changed how cache works. > > On 04/18/2011 03:06 PM, Andrew Su wrote: > > >> > > >> Are the markCompressed/isCompressed methods used anywhere? If > > >> not, > > >> could you please make that a separate patch? > > > > > > Yes, I've added the use of isCompressed in CacheEntry.isCached(). > > > Reason being that if the item was extracted, the content-length > > > reported > > > by the connection would differ from actual file size, thus forcing > > > it to > > > download without actually checking the modified time. > > > > > > > That is a problem, but it seems orthogonal to the rest of the patch. > > I > > am not sure simply ignoring the content-length for compressed files > > is > > the best thing to do. We wont be able to detect changes in file > > size. > > Perhaps we should be storing uncompressed size instead? > > We can discuss a more on this after this gets in. > > > > > > > > > Is the patch okay now? > > > > > > > I would have preferred it if the isCompressed() and related stuff > > were > > in a separate patch - the rest of the stuff looks ok to me. > > > Cheers, > Andrew From omajid at redhat.com Mon Apr 18 14:01:00 2011 From: omajid at redhat.com (Omair Majid) Date: Mon, 18 Apr 2011 17:01:00 -0400 Subject: [RFC][Icedtea-web]: Changed how cache works. In-Reply-To: <1486595406.42463.1303155709627.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1486595406.42463.1303155709627.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <4DACA68C.2040900@redhat.com> On 04/18/2011 03:41 PM, Andrew Su wrote: > > Ok to push after removing the checks for compression? > Yup. Looks fine to me. Cheers, Omair From asu at icedtea.classpath.org Mon Apr 18 14:36:31 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Mon, 18 Apr 2011 21:36:31 +0000 Subject: /hg/icedtea-web: Changed cache to prevent jar overwriting when u... Message-ID: changeset 211a5e73d119 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=211a5e73d119 author: Andrew Su date: Mon Apr 18 17:38:31 2011 -0400 Changed cache to prevent jar overwriting when update happens. diffstat: ChangeLog | 42 ++ netx/net/sourceforge/jnlp/cache/CacheEntry.java | 20 + netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java | 245 +++++++++++++++++ netx/net/sourceforge/jnlp/cache/CacheUtil.java | 200 ++++++++++++- netx/net/sourceforge/jnlp/cache/ResourceTracker.java | 133 +++++--- netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java | 4 +- netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java | 1 + netx/net/sourceforge/jnlp/util/FileUtils.java | 42 ++ netx/net/sourceforge/jnlp/util/XDesktopEntry.java | 2 +- 9 files changed, 624 insertions(+), 65 deletions(-) diffs (truncated from 857 to 500 lines): diff -r 37f99d9fbdeb -r 211a5e73d119 ChangeLog --- a/ChangeLog Mon Apr 18 15:13:23 2011 -0400 +++ b/ChangeLog Mon Apr 18 17:38:31 2011 -0400 @@ -1,3 +1,45 @@ +2011-04-18 Andrew Su + + * netx/net/sourceforge/jnlp/cache/CacheEntry.java: + (markForDelete): New method. Adds an entry to info file specifying + that this file should be delete. + (lock): New method. Locks the info file. + (unlock): New method. Unlocks the info file. + * netx/net/sourceforge/jnlp/cache/CacheUtil.java: + (cacheDir, lruHandler, propertiesLockPool): New private static fields. + (clearCache): Changed to use static field. + (getCacheFile): Changed to call getCacheFileIfExist and + makeNewCacheFile where appropriate. + (getCacheFileIfExist): New method. Get the file of requested item. + (makeNewCacheFile): New method. Create a new location to store cache + file. + (pathToURLPath): New method. Convert the file path to the url path. + (cleanCache): New method. Search for redundant entries and remove + them. + (removeUntrackedDirectories): New method. Remove all untracked + directories. + (lockFile): New method. Locks the given property file. + (unlockFile): New method. Unlocks the property file if we locked + before. + * netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java: New class. + Provides wrappers for handling cache's LRU. + * netx/net/sourceforge/jnlp/cache/ResourceTracker.java: + (downloadResource): Ensure that we only allow downloading the + specified file once. + (initializeResource): Added creation of new location to store an + updated or new file. + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: + (JNLPClassLoader): Reordered the calls since we should check + permission after we have the files ready. + * netx/net/sourceforge/jnlp/runtime/JNLPRuntime.java: + (markNetxRunning): Added call to CacheUtil.cleanCache() when adding + shutdown hooks. + * netx/net/sourceforge/jnlp/util/FileUtils.java: + (getFileLock): New method. + * netx/net/sourceforge/jnlp/util/XDesktopEntry.java: + (getContentsAsReader): Changed call from using urlToPath to + getCacheFile, since the directories are no longer in that location. + 2011-04-18 Denis Lila * netx/net/sourceforge/jnlp/Launcher.java: diff -r 37f99d9fbdeb -r 211a5e73d119 netx/net/sourceforge/jnlp/cache/CacheEntry.java --- a/netx/net/sourceforge/jnlp/cache/CacheEntry.java Mon Apr 18 15:13:23 2011 -0400 +++ b/netx/net/sourceforge/jnlp/cache/CacheEntry.java Mon Apr 18 17:38:31 2011 -0400 @@ -162,4 +162,24 @@ properties.store(); } + /** + * Mark this entry for deletion at shutdown. + */ + public void markForDelete() { // once marked it should not be unmarked. + properties.setProperty("delete", Boolean.toString(true)); + } + + /** + * Lock cache item. + */ + protected void lock() { + CacheUtil.lockFile(properties); + } + + /** + * Unlock cache item. + */ + protected void unlock() { + CacheUtil.unlockFile(properties); + } } diff -r 37f99d9fbdeb -r 211a5e73d119 netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/netx/net/sourceforge/jnlp/cache/CacheLRUWrapper.java Mon Apr 18 17:38:31 2011 -0400 @@ -0,0 +1,245 @@ +/* CacheLRUWrapper -- Handle LRU for cache files. + Copyright (C) 2011 Red Hat, Inc. + +This file is part of IcedTea. + +IcedTea is free software; you can redistribute it and/or +modify it under the terms of the GNU General Public License as published by +the Free Software Foundation, version 2. + +IcedTea is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +General Public License for more details. + +You should have received a copy of the GNU General Public License +along with IcedTea; see the file COPYING. If not, write to +the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA +02110-1301 USA. + +Linking this library statically or dynamically with other modules is +making a combined work based on this library. Thus, the terms and +conditions of the GNU General Public License cover the whole +combination. + +As a special exception, the copyright holders of this library give you +permission to link this library with independent modules to produce an +executable, regardless of the license terms of these independent +modules, and to copy and distribute the resulting executable under +terms of your choice, provided that you also meet, for each linked +independent module, the terms and conditions of the license of that +module. An independent module is a module which is not derived from +or based on this library. If you modify this library, you may extend +this exception to your version of the library, but you are not +obligated to do so. If you do not wish to do so, delete this +exception statement from your version. + */ +package net.sourceforge.jnlp.cache; + +import java.io.File; +import java.io.IOException; +import java.nio.channels.FileLock; +import java.nio.channels.OverlappingFileLockException; +import java.util.ArrayList; +import java.util.Collections; +import java.util.Comparator; +import java.util.List; +import java.util.Map.Entry; + +import net.sourceforge.jnlp.config.DeploymentConfiguration; +import net.sourceforge.jnlp.runtime.JNLPRuntime; +import net.sourceforge.jnlp.util.FileUtils; +import net.sourceforge.jnlp.util.PropertiesFile; + +/** + * This class helps maintain the ordering of most recently use items across + * multiple jvm instances. + * + * @author Andrew Su (asu at redhat.com, andrew.su at utoronto.ca) + * + */ +enum CacheLRUWrapper { + INSTANCE; + + private int lockCount = 0; + + /* lock for the file RecentlyUsed */ + private FileLock fl = null; + + /* location of cache directory */ + private final String cacheDir = new File(JNLPRuntime.getConfiguration() + .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)).getPath(); + + /* + * back-end of how LRU is implemented This file is to keep track of the most + * recently used items. The items are to be kept with key = (current time + * accessed) followed by folder of item. value = path to file. + */ + private PropertiesFile cacheOrder = new PropertiesFile( + new File(cacheDir + File.separator + "recently_used")); + + /** + * Returns an instance of the policy. + * + * @param propertiesFile + * @return + */ + public static CacheLRUWrapper getInstance() { + return INSTANCE; + } + + /** + * Update map for keeping track of recently used items. + */ + public synchronized void load() { + cacheOrder.load(); + } + + /** + * Write file to disk. + */ + public synchronized void store() { + cacheOrder.store(); + } + + /** + * This adds a new entry to file. + * + * @param key key we want path to be associated with. + * @param path path to cache item. + * @return true if we successfully added to map, false otherwise. + */ + public synchronized boolean addEntry(String key, String path) { + if (cacheOrder.containsKey(key)) return false; + cacheOrder.setProperty(key, path); + return true; + } + + /** + * This removed an entry from our map. + * + * @param key key we want to remove. + * @return true if we successfully removed key from map, false otherwise. + */ + public synchronized boolean removeEntry(String key) { + if (!cacheOrder.containsKey(key)) return false; + cacheOrder.remove(key); + return true; + } + + private String getIdForCacheFolder(String folder) { + int len = cacheDir.length(); + int index = folder.indexOf(File.separatorChar, len + 1); + return folder.substring(len + 1, index); + } + + /** + * This updates the given key to reflect it was recently accessed. + * + * @param oldKey Key we wish to update. + * @return true if we successfully updated value, false otherwise. + */ + public synchronized boolean updateEntry(String oldKey) { + if (!cacheOrder.containsKey(oldKey)) return false; + String value = cacheOrder.getProperty(oldKey); + String folder = getIdForCacheFolder(value); + + cacheOrder.remove(oldKey); + cacheOrder.setProperty(Long.toString(System.currentTimeMillis()) + "," + folder, value); + return true; + } + + /** + * Return a copy of the keys available. + * + * @return List of Strings sorted by ascending order. + */ + public synchronized List> getLRUSortedEntries() { + ArrayList> entries = new ArrayList(cacheOrder.entrySet()); + // sort by keys in descending order. + Collections.sort(entries, new Comparator>() { + @Override + public int compare(Entry e1, Entry e2) { + try { + Long t1 = Long.parseLong(e1.getKey().split(",")[0]); + Long t2 = Long.parseLong(e2.getKey().split(",")[0]); + + int c = t1.compareTo(t2); + return c < 0 ? 1 : (c > 0 ? -1 : 0); + } catch (NumberFormatException e) { + // Perhaps an error is too harsh. Maybe just somehow turn + // caching off if this is the case. + throw new InternalError("Corrupt LRU file entries"); + } + } + }); + return entries; + } + + /** + * Lock the file to have exclusive access. + */ + public synchronized void lock() { + try { + File f = cacheOrder.getStoreFile(); + if (!f.exists()) { + FileUtils.createParentDir(f); + FileUtils.createRestrictedFile(f, true); + } + fl = FileUtils.getFileLock(f.getPath(), false, true); + } catch (OverlappingFileLockException e) { // if overlap we just increase the count. + } catch (Exception e) { // We didn't get a lock.. + e.printStackTrace(); + } + if (fl != null) lockCount++; + } + + /** + * Unlock the file. + */ + public synchronized void unlock() { + if (fl != null) { + lockCount--; + try { + if (lockCount == 0) { + fl.release(); + fl.channel().close(); + fl = null; + } + } catch (IOException e) { + e.printStackTrace(); + } + } + } + + /** + * Return the value of given key. + * + * @param key + * @return value of given key, null otherwise. + */ + public synchronized String getValue(String key) { + return cacheOrder.getProperty(key); + } + + /** + * Test if we the key provided is in use. + * + * @param key key to be tested. + * @return true if the key is in use. + */ + public synchronized boolean contains(String key) { + return cacheOrder.contains(key); + } + + /** + * Generate a key given the path to file. May or may not generate the same + * key given same path. + * + * @param path Path to generate a key with. + * @return String representing the a key. + */ + public String generateKey(String path) { + return System.currentTimeMillis() + "," + getIdForCacheFolder(path); + } +} diff -r 37f99d9fbdeb -r 211a5e73d119 netx/net/sourceforge/jnlp/cache/CacheUtil.java --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 15:13:23 2011 -0400 +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 17:38:31 2011 -0400 @@ -21,7 +21,14 @@ import java.io.*; import java.net.*; import java.nio.channels.FileChannel; -import java.util.*; +import java.nio.channels.FileLock; +import java.nio.channels.OverlappingFileLockException; +import java.util.ArrayList; +import java.util.HashMap; +import java.util.HashSet; +import java.util.List; +import java.util.Map.Entry; +import java.util.Set; import java.security.*; import javax.jnlp.*; @@ -29,6 +36,7 @@ import net.sourceforge.jnlp.config.DeploymentConfiguration; import net.sourceforge.jnlp.runtime.*; import net.sourceforge.jnlp.util.FileUtils; +import net.sourceforge.jnlp.util.PropertiesFile; /** * Provides static methods to interact with the cache, download @@ -39,6 +47,11 @@ */ public class CacheUtil { + private static final String cacheDir = new File(JNLPRuntime.getConfiguration() + .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)).getPath(); // Do this with file to standardize it. + private static final CacheLRUWrapper lruHandler = CacheLRUWrapper.getInstance(); + private static final HashMap propertiesLockPool = new HashMap(); + /** * Compares a URL using string compare of its protocol, host, * port, path, query, and anchor. This method avoids the host @@ -138,8 +151,7 @@ return; } - File cacheDir = new File(JNLPRuntime.getConfiguration() - .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR)); + File cacheDir = new File(CacheUtil.cacheDir); if (!(cacheDir.isDirectory())) { return; } @@ -284,18 +296,95 @@ if (!isCacheable(source, version)) throw new IllegalArgumentException(R("CNotCacheable", source)); - try { - String cacheDir = JNLPRuntime.getConfiguration() - .getProperty(DeploymentConfiguration.KEY_USER_CACHE_DIR); - File localFile = urlToPath(source, cacheDir); - FileUtils.createParentDir(localFile); + File cacheFile = null; + synchronized (lruHandler) { + lruHandler.lock(); - return localFile; - } catch (Exception ex) { - if (JNLPRuntime.isDebug()) - ex.printStackTrace(); + // We need to reload the cacheOrder file each time + // since another plugin/javaws instance may have updated it. + lruHandler.load(); + cacheFile = getCacheFileIfExist(urlToPath(source, "")); + if (cacheFile == null) { // We did not find a copy of it. + cacheFile = makeNewCacheFile(source, version); + } + lruHandler.unlock(); + } + return cacheFile; + } - return null; + /** + * This will return a File pointing to the location of cache item. + * + * @param urlPath Path of cache item within cache directory. + * @return File if we have searched before, null otherwise. + */ + private static File getCacheFileIfExist(File urlPath) { + synchronized (lruHandler) { + File cacheFile = null; + List> entries = lruHandler.getLRUSortedEntries(); + // Start searching from the most recent to least recent. + for (Entry e : entries) { + final String key = e.getKey(); + final String path = e.getValue(); + + if (path != null) { + if (pathToURLPath(path).equals(urlPath.getPath())) { // Match found. + cacheFile = new File(path); + lruHandler.updateEntry(key); + break; // Stop searching since we got newest one already. + } + } + } + return cacheFile; + } + } + + /** + * Get the path to file minus the cache directory and indexed folder. + */ + private static String pathToURLPath(String path) { + int len = cacheDir.length(); + int index = path.indexOf(File.separatorChar, len + 1); + return path.substring(index); + } + + /** + * This will create a new entry for the cache item. It is however not + * initialized but any future calls to getCacheFile with the source and + * version given to here, will cause it to return this item. + * + * @param source the source URL + * @param version the version id of the local file + * @return the file location in the cache. + */ + public static File makeNewCacheFile(URL source, Version version) { + synchronized (lruHandler) { + lruHandler.lock(); + lruHandler.load(); + + File cacheFile = null; + for (long i = 0; i < Long.MAX_VALUE; i++) { + String path = cacheDir + File.separator + i; + File cDir = new File(path); + if (!cDir.exists()) { + // We can use this directory. + try { + cacheFile = urlToPath(source, path); + FileUtils.createParentDir(cacheFile); + File pf = new File(cacheFile.getPath() + ".info"); + FileUtils.createRestrictedFile(pf, true); // Create the info file for marking later. + lruHandler.addEntry(lruHandler.generateKey(cacheFile.getPath()), cacheFile.getPath()); + } catch (IOException ioe) { + ioe.printStackTrace(); + } + + break; + } + } + + lruHandler.store(); + lruHandler.unlock(); + return cacheFile; } } @@ -436,4 +525,89 @@ } } + /** + * This will remove all old cache items. + */ + public static void cleanCache() { + if (okToClearCache()) { + // First we want to figure out which stuff we need to delete. + HashSet keep = new HashSet(); + lruHandler.load(); + + for (Entry e : lruHandler.getLRUSortedEntries()) { + // Check if the item is contained in cacheOrder. + final String key = e.getKey(); + final String value = e.getValue(); + + if (value != null) { From bugzilla-daemon at icedtea.classpath.org Mon Apr 18 14:57:40 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 18 Apr 2011 21:57:40 +0000 Subject: [Bug 694] New: ZeroVM fails to build from source Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=694 Summary: ZeroVM fails to build from source Product: IcedTea Version: 7-hg Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Zero AssignedTo: unassigned at icedtea.classpath.org ReportedBy: drazzib at drazzib.com Hi, I've just tried to build icedtea7 b130 (from icedtea hg) from source. HotspotVM build fine but it seems ZeroVM just FTBFS. /home/drazzib/Dev/debian-pkg/openjdk/openjdk-7-7~b130-1.14~pre1/build/zerovm/openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function 'static void BytecodeInterpreter::run( BytecodeInterpreter*)': /home/drazzib/Dev/debian-pkg/openjdk/openjdk-7-7~b130-1.14~pre1/build/zerovm/openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:1945: error: 'class constantPoolOopDesc' has no member named 'obj _at_addr' /home/drazzib/Dev/debian-pkg/openjdk/openjdk-7-7~b130-1.14~pre1/build/zerovm/openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:2035: error: 'class constantPoolOopDesc' has no member named 'obj _at_addr' /home/drazzib/Dev/debian-pkg/openjdk/openjdk-7-7~b130-1.14~pre1/build/zerovm/openjdk/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:2070: error: 'class constantPoolOopDesc' has no member named 'obj _at_addr' Regards, -- Damien Raude-Morvan -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From asu at redhat.com Mon Apr 18 20:02:58 2011 From: asu at redhat.com (Andrew Su) Date: Mon, 18 Apr 2011 23:02:58 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <1214095085.46878.1303182098662.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1292960503.46884.1303182178480.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hello, This patch will ensure the cache size will remain at most the size specified in the user's deployment's properties file. This is executed only at jvm shutdown of the plugin and/or javaws. Questions? Comments? Concerns? Regards, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110418_cache_limit.patch Type: text/x-patch Size: 2200 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110418/b2ed5914/20110418_cache_limit.patch From dbhole at redhat.com Mon Apr 18 22:22:12 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 19 Apr 2011 01:22:12 -0400 Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <1292960503.46884.1303182178480.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1214095085.46878.1303182098662.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <1292960503.46884.1303182178480.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110419052211.GA5444@redhat.com> * Andrew Su [2011-04-18 23:04]: > Hello, > > This patch will ensure the cache size will remain at most the size specified in the user's deployment's properties file. > > This is executed only at jvm shutdown of the plugin and/or javaws. > > Questions? Comments? Concerns? > > Regards, > Andrew > diff -r 211a5e73d119 netx/net/sourceforge/jnlp/cache/CacheUtil.java > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 17:38:31 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 22:58:38 2011 -0400 > @@ -533,6 +533,15 @@ > // First we want to figure out which stuff we need to delete. > HashSet keep = new HashSet(); > lruHandler.load(); > + > + long maxSize = -1; // Default > + try { > + maxSize = Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); > + } catch (NumberFormatException nfe) { > + } > + > + maxSize = maxSize << 20; // Convert to byte (Should not overflow..) Please clarify the above comment along the lines of "Convert from megabytes to bytes" or something, as it is not immediately clear. > + long curSize = 0; > > for (Entry e : lruHandler.getLRUSortedEntries()) { > // Check if the item is contained in cacheOrder. > @@ -540,16 +549,19 @@ > final String value = e.getValue(); > > if (value != null) { > + File file = new File(value); > PropertiesFile pf = new PropertiesFile(new File(value + ".info")); > boolean delete = Boolean.parseBoolean(pf.getProperty("delete")); > > // This will get me the root directory specific to this cache item. > - String rStr = value.substring(cacheDir.length()); > + String rStr = file.getPath().substring(cacheDir.length()); > rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1)); This is rather convoluted. Can you add an example in the comments stating exactly what each of the above lines do to a sample "value"? >From what I can tell, it is just getting the dirname of the file. If that is correct, why not use File.getParentFile()? > + long len = file.length(); > > - if (delete || keep.contains(rStr)) { > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > maxSize) || keep.contains(rStr)) { Can you clarify the logic here (in a comment as well) please? 1. if delete == true, delete .... this is OK 2. if !file.isFile() .... would getLRUSortedEntries() ever return a dir? 3. (maxSize >= 0 && curSize + len > maxSize) ... okay, sounds reasonable, this is current behaviour 4. keep.contains(rStr) ... the else part of that block adds rStr to keep. Can there be a case where it shows up again during the iteration? Cheers, Deepak > lruHandler.removeEntry(key); > } else { > + curSize += len; > keep.add(value.substring(rStr.length())); > keep.add(rStr); // We can just use the same map, since these two things are disjoint with each other. > } From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 01:41:08 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 08:41:08 +0000 Subject: [Bug 694] ZeroVM fails to build from source In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=694 Gary Benson changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gbenson at redhat.com --- Comment #1 from Gary Benson 2011-04-19 08:41:08 --- Looks like you are missing this change: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/173926398291/src/share/vm/interpreter/bytecodeInterpreter.cpp -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 02:49:40 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 09:49:40 +0000 Subject: [Bug 694] ZeroVM fails to build from source In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=694 --- Comment #2 from Xerxes R?nby 2011-04-19 09:49:39 --- Created an attachment (id=518) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=518) pr694-a.patch Thank you Gary, by creating a patch pr694-a.patch out of the http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/173926398291/src/share/vm/interpreter/bytecodeInterpreter.cpp part from hotspot-comp the build now progress furter: g++ -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DIA32 -DZERO_LIBARCH=\"i386\" -DPRODUCT -I. -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm/prims -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/cpu/zero/vm -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/os_cpu/linux_zero/vm -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/os/linux/vm -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"21.0-b02\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"xerxes\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0_130-b130\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea7 1.14-pre+r2cd959df7e7a\"" -DDISTRIBUTION_ID="\"Built on Ubuntu 10.10 (Tue Apr 19 11:34:42 CEST 2011)\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_zero -DTARGET_ARCH_MODEL_zero -DTARGET_OS_ARCH_linux_zero -DTARGET_OS_ARCH_MODEL_linux_zero -DTARGET_COMPILER_gcc -DSHARK -I/usr/local/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DSHARK_LLVM_VERSION=29 -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m32 -pipe -g -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/ciUtilities.o.d -o ciUtilities.o /home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm/ci/ciUtilities.cpp /home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm/ci/ciTypeFlow.cpp: In member function 'void ciTypeFlow::df_flow_types(ciTypeFlow::Block*, bool, ciTypeFlow::StateVector*, ciTypeFlow::JsrSet*)': /home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm/ci/ciTypeFlow.cpp:2632: error: 'MaxNodeLimit' was not declared in this scope make[7]: *** [ciTypeFlow.o] Error 1 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 02:53:34 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 09:53:34 +0000 Subject: [Bug 639] Shark fails with hs20 In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=639 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerxes at zafena.se --- Comment #5 from Xerxes R?nby 2011-04-19 09:53:34 --- (In reply to comment #4) > Jumped too soon: > > dl failure on line 696Error: failed > /mnt/builder/shark6/openjdk.build-ecj/j2sdk-image/jre/lib/amd64/server/libjvm.so, > because libLLVM-2.8.so: cannot open shared object file: No such file or > directory > /home/andrew/builder/shark6/bootstrap/jdk1.6.0/bin/java cannot be found or is > corrupted. > when i hit this error on my maching the i usually do one of the following to resolve this issue: a) run make install from myllvm build dir and then run ldconfig. b) copy the libLLVM-2.8.so to mnt/builder/shark6/openjdk.build-ecj/j2sdk-image/jre/lib/amd64/server/ -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 02:55:58 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 09:55:58 +0000 Subject: [Bug 694] ZeroVM fails to build from source In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=694 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerxes at zafena.se --- Comment #3 from Xerxes R?nby 2011-04-19 09:55:58 --- (In reply to comment #2) > Created an attachment (id=518) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=518) [details] > pr694-a.patch > > Thank you Gary, by creating a patch pr694-a.patch out of the > http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/173926398291/src/share/vm/interpreter/bytecodeInterpreter.cpp > part from hotspot-comp the build now progress furter: > > g++ -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DIA32 -DZERO_LIBARCH=\"i386\" > -DPRODUCT -I. > -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm/prims > -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm > -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/cpu/zero/vm > -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/os_cpu/linux_zero/vm > -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/os/linux/vm > -I/home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/os/posix/vm > -I../generated -DHOTSPOT_RELEASE_VERSION="\"21.0-b02\"" > -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"xerxes\"" > -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0_130-b130\"" > -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea7 > 1.14-pre+r2cd959df7e7a\"" -DDISTRIBUTION_ID="\"Built on Ubuntu 10.10 (Tue Apr > 19 11:34:42 CEST 2011)\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_zero > -DTARGET_ARCH_MODEL_zero -DTARGET_OS_ARCH_linux_zero > -DTARGET_OS_ARCH_MODEL_linux_zero -DTARGET_COMPILER_gcc -DSHARK > -I/usr/local/include -D_GNU_SOURCE -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS -DSHARK_LLVM_VERSION=29 -fpic -fno-rtti > -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m32 -pipe -g -O3 > -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wsign-compare > -c -MMD -MP -MF ../generated/dependencies/ciUtilities.o.d -o ciUtilities.o > /home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm/ci/ciUtilities.cpp > /home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm/ci/ciTypeFlow.cpp: > In member function 'void ciTypeFlow::df_flow_types(ciTypeFlow::Block*, bool, > ciTypeFlow::StateVector*, ciTypeFlow::JsrSet*)': > /home/xerxes/icedtea-shark/openjdk-boot/hotspot/src/share/vm/ci/ciTypeFlow.cpp:2632: > error: 'MaxNodeLimit' was not declared in this scope > make[7]: *** [ciTypeFlow.o] Error 1 > this part looks like http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=639 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 03:05:16 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 10:05:16 +0000 Subject: [Bug 694] ZeroVM fails to build from source In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=694 --- Comment #4 from Gary Benson 2011-04-19 10:05:16 --- http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/diff/e863062e521d/src/share/vm/ci/ciTypeFlow.hpp -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From andrew at icedtea.classpath.org Tue Apr 19 05:34:08 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Tue, 19 Apr 2011 12:34:08 +0000 Subject: /hg/icedtea: Incorporate Zero/Shark fixes and security fix. Message-ID: changeset dbc0c1e6323c in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=dbc0c1e6323c author: Andrew John Hughes date: Tue Apr 19 13:33:51 2011 +0100 Incorporate Zero/Shark fixes and security fix. 2011-04-19 Andrew John Hughes * Makefile.am: (HOTSPOT_CHANGESET): Incorporate Zero/Shark fixes and security fix. (HOTSPOT_SHA256SUM): Likewise. diffstat: ChangeLog | 7 +++++++ Makefile.am | 4 ++-- 2 files changed, 9 insertions(+), 2 deletions(-) diffs (35 lines): diff -r 2cd959df7e7a -r dbc0c1e6323c ChangeLog --- a/ChangeLog Mon Apr 18 18:03:43 2011 +0100 +++ b/ChangeLog Tue Apr 19 13:33:51 2011 +0100 @@ -1,3 +1,10 @@ +2011-04-19 Andrew John Hughes + + * Makefile.am: + (HOTSPOT_CHANGESET): Incorporate Zero/Shark fixes + and security fix. + (HOTSPOT_SHA256SUM): Likewise. + 2011-04-18 Andrew John Hughes * Makefile.am: diff -r 2cd959df7e7a -r dbc0c1e6323c Makefile.am --- a/Makefile.am Mon Apr 18 18:03:43 2011 +0100 +++ b/Makefile.am Tue Apr 19 13:33:51 2011 +0100 @@ -3,7 +3,7 @@ OPENJDK_VERSION = b130 CORBA_CHANGESET = 59f02c101698 -HOTSPOT_CHANGESET = bbfa41dad6d4 +HOTSPOT_CHANGESET = 7069a3b8a90a JAXP_CHANGESET = b6f201c0649a JAXWS_CHANGESET = 4c04de31900b JDK_CHANGESET = f6ac05b155d6 @@ -11,7 +11,7 @@ OPENJDK_CHANGESET = d39d0c08731a CORBA_SHA256SUM = 4c6db5299947c3ed11a7f72da55a3cd89197c143f10d77c75036aa2f2cf296a6 -HOTSPOT_SHA256SUM = bf4f93ae5782e4110ffc33fdc997c4c43f798eca9dff6db4784f8da51ff0f2c3 +HOTSPOT_SHA256SUM = 24da70ad4f2902269e0bb3a1a693dd15dfe1906c6f8019368be704915bccdb54 JAXP_SHA256SUM = a1a5c6b2671f83d4675f9ba25013c6a16a4cf4d1040fcd2ff4143c92bd5496a3 JAXWS_SHA256SUM = 8fe84a61142d579487bee98133fc26e57aedb97f781dc925ad3803aa40f5c061 JDK_SHA256SUM = 564e9c9f7d6335d8fe221389893462dbb3daf4a20d9e75ffa37e9c8bbd7687be From asu at redhat.com Tue Apr 19 06:46:48 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 19 Apr 2011 09:46:48 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <20110419052211.GA5444@redhat.com> Message-ID: <240630093.55422.1303220808957.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Deepak Bhole" > To: "Andrew Su" > Cc: "IcedTea" > Sent: Tuesday, April 19, 2011 1:22:12 AM > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > * Andrew Su [2011-04-18 23:04]: > > Hello, > > > > This patch will ensure the cache size will remain at most the size > > specified in the user's deployment's properties file. > > > > This is executed only at jvm shutdown of the plugin and/or javaws. > > > > Questions? Comments? Concerns? > > > > Regards, > > Andrew > > > diff -r 211a5e73d119 netx/net/sourceforge/jnlp/cache/CacheUtil.java > > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 > > 17:38:31 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 > > 22:58:38 2011 -0400 > > @@ -533,6 +533,15 @@ > > // First we want to figure out which stuff we need to > > delete. > > HashSet keep = new HashSet(); > > lruHandler.load(); > > + > > + long maxSize = -1; // Default > > + try { > > + maxSize = > > Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); > > + } catch (NumberFormatException nfe) { > > + } > > + > > + maxSize = maxSize << 20; // Convert to byte (Should not > > overflow..) > > Please clarify the above comment along the lines of "Convert from > megabytes to bytes" or something, as it is not immediately clear. done > > > + long curSize = 0; > > > > for (Entry e : > > lruHandler.getLRUSortedEntries()) { > > // Check if the item is contained in cacheOrder. > > @@ -540,16 +549,19 @@ > > final String value = e.getValue(); > > > > if (value != null) { > > + File file = new File(value); > > PropertiesFile pf = new PropertiesFile(new > > File(value + ".info")); > > boolean delete = > > Boolean.parseBoolean(pf.getProperty("delete")); > > > > // This will get me the root directory specific > > to this cache item. > > - String rStr = value.substring(cacheDir.length()); > > + String rStr = file.getPath().substring(cacheDir.length()); > > rStr = cacheDir + rStr.substring(0, > > rStr.indexOf(File.separatorChar, 1)); > > This is rather convoluted. Can you add an example in the comments > stating exactly what each of the above lines do to a sample "value"? > > From what I can tell, it is just getting the dirname of the file. If > that is correct, why not use File.getParentFile()? When I said root directory, I meant it as in the unique folder to the item. Such as "/home/user1/.icedtea/cache/3" > > > > + long len = file.length(); > > > > - if (delete || keep.contains(rStr)) { > > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > > > maxSize) || keep.contains(rStr)) { > > Can you clarify the logic here (in a comment as well) please? > > 1. if delete == true, delete .... this is OK > > 2. if !file.isFile() .... would getLRUSortedEntries() ever return a > dir? No, and it shouldn't, but let's say, directory was created but the actual item doesn't exist. If the item wasn't marked for deletion we'll have an empty folder lying around, should get rid of it. (This seems to go with previous patch more, missed this case) > > 3. (maxSize >= 0 && curSize + len > maxSize) ... okay, sounds > reasonable, this is current behaviour > > 4. keep.contains(rStr) ... the else part of that block adds rStr to > keep. Can there be a case where it shows up again during the > iteration? Nope, it doesn't the second add to keep is for use with removeUntrackedDirectories() Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: 20110419_cache_limit_v2.patch Type: text/x-patch Size: 3419 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110419/422ea5ef/20110419_cache_limit_v2.patch From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 07:07:07 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 14:07:07 +0000 Subject: [Bug 694] ZeroVM fails to build from source In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=694 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gnu_andrew at member.fsf.org Status|NEW |RESOLVED Resolution| |FIXED --- Comment #5 from Andrew John Hughes 2011-04-19 14:07:06 --- 7018673: Zero: 6953144, 6990754 and 7009756 made some changes which broke Zero 7032775: Include Shark code in the build again 7036220: Shark fails to find LLVM 2.9 System headers during build 6878713: Verifier heap corruption, relating to backward jsrs 7032458: Zero and Shark fixes are all now in the IcedTea forest. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dbhole at redhat.com Tue Apr 19 07:14:37 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 19 Apr 2011 10:14:37 -0400 Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <240630093.55422.1303220808957.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <20110419052211.GA5444@redhat.com> <240630093.55422.1303220808957.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110419141437.GA15825@redhat.com> * Andrew Su [2011-04-19 09:46]: > > > > > > When I said root directory, I meant it as in the unique folder to the item. > Such as "/home/user1/.icedtea/cache/3" > Okay. That will nuke everything in the cache from existing (current format) cache dirs, but it is okay as that cache will never get used anyway. > > > > > > > + long len = file.length(); > > > > > > - if (delete || keep.contains(rStr)) { > > > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > > > > maxSize) || keep.contains(rStr)) { > > > > Can you clarify the logic here (in a comment as well) please? > > > > 1. if delete == true, delete .... this is OK > > > > 2. if !file.isFile() .... would getLRUSortedEntries() ever return a > > dir? > > No, and it shouldn't, but let's say, directory was created but the > actual item doesn't exist. If the item wasn't marked for deletion > we'll have an empty folder lying around, should get rid of it. > (This seems to go with previous patch more, missed this case) > Fair enough. > > > > 3. (maxSize >= 0 && curSize + len > maxSize) ... okay, sounds > > reasonable, this is current behaviour > > > > 4. keep.contains(rStr) ... the else part of that block adds rStr to > > keep. Can there be a case where it shows up again during the > > iteration? > > Nope, it doesn't the second add to keep is for use with removeUntrackedDirectories() > Cheers, Okay. One last thing that just came to mind.. if I accidentally specify $HOME as the cachedir with size < sizeof($HOME), won't this patch nuke all of it? Deepak > Andrew > diff -r 211a5e73d119 netx/net/sourceforge/jnlp/cache/CacheUtil.java > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 17:38:31 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Tue Apr 19 09:33:42 2011 -0400 > @@ -533,6 +533,15 @@ > // First we want to figure out which stuff we need to delete. > HashSet keep = new HashSet(); > lruHandler.load(); > + > + long maxSize = -1; // Default > + try { > + maxSize = Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); > + } catch (NumberFormatException nfe) { > + } > + > + maxSize = maxSize << 20; // Convert from megabyte to byte (Negative values will be considered unlimited.) > + long curSize = 0; > > for (Entry e : lruHandler.getLRUSortedEntries()) { > // Check if the item is contained in cacheOrder. > @@ -540,16 +549,37 @@ > final String value = e.getValue(); > > if (value != null) { > + File file = new File(value); > PropertiesFile pf = new PropertiesFile(new File(value + ".info")); > boolean delete = Boolean.parseBoolean(pf.getProperty("delete")); > > - // This will get me the root directory specific to this cache item. > - String rStr = value.substring(cacheDir.length()); > + /* > + * This will get me the root directory specific to this cache item. > + * Example: > + * cacheDir = /home/user1/.icedtea/cache > + * file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar > + * rStr first becomes: /0/http/www.example.com/subdir/a.jar > + * then rstr becomes: /home/user1/.icedtea/cache/0 > + */ > + String rStr = file.getPath().substring(cacheDir.length()); > rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1)); > + long len = file.length(); > > - if (delete || keep.contains(rStr)) { > + /* > + * we remove entries from our lru if any of the following condition is met. > + * Conditions: > + * - delete: file has been marked for deletion. > + * - !file.isFile(): if someone tampered with the directory, file doesn't exist. > + * - maxSize >= 0 && curSize + len > maxSize: If a limit was set and the new size > + * on disk would exceed the maximum size. > + * - keep.contains(rStr): We had already decided to keep an entry with the same > + * url path. > + * > + */ > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > maxSize) || keep.contains(rStr)) { > lruHandler.removeEntry(key); > } else { > + curSize += len; > keep.add(value.substring(rStr.length())); > keep.add(rStr); // We can just use the same map, since these two things are disjoint with each other. > } From andrew at icedtea.classpath.org Tue Apr 19 07:22:13 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Tue, 19 Apr 2011 14:22:13 +0000 Subject: /hg/icedtea: Incorporate ARM interpreter code removal, JSR 292 Z... Message-ID: changeset 41bcdf9bf8c1 in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=41bcdf9bf8c1 author: Andrew John Hughes date: Tue Apr 19 15:22:08 2011 +0100 Incorporate ARM interpreter code removal, JSR 292 Zero support and merge issue fix. 2011-04-19 Andrew John Hughes * Makefile.am: (HOTSPOT_CHANGESET): Incorporate ARM interpreter code removal, JSR 292 Zero support and merge issue fix. (HOTSPOT_SHA256SUM): Likewise. diffstat: ChangeLog | 7 +++++++ Makefile.am | 4 ++-- 2 files changed, 9 insertions(+), 2 deletions(-) diffs (35 lines): diff -r dbc0c1e6323c -r 41bcdf9bf8c1 ChangeLog --- a/ChangeLog Tue Apr 19 13:33:51 2011 +0100 +++ b/ChangeLog Tue Apr 19 15:22:08 2011 +0100 @@ -1,3 +1,10 @@ +2011-04-19 Andrew John Hughes + + * Makefile.am: + (HOTSPOT_CHANGESET): Incorporate ARM interpreter + code removal, JSR 292 Zero support and merge issue fix. + (HOTSPOT_SHA256SUM): Likewise. + 2011-04-19 Andrew John Hughes * Makefile.am: diff -r dbc0c1e6323c -r 41bcdf9bf8c1 Makefile.am --- a/Makefile.am Tue Apr 19 13:33:51 2011 +0100 +++ b/Makefile.am Tue Apr 19 15:22:08 2011 +0100 @@ -3,7 +3,7 @@ OPENJDK_VERSION = b130 CORBA_CHANGESET = 59f02c101698 -HOTSPOT_CHANGESET = 7069a3b8a90a +HOTSPOT_CHANGESET = 4071da7ef7b3 JAXP_CHANGESET = b6f201c0649a JAXWS_CHANGESET = 4c04de31900b JDK_CHANGESET = f6ac05b155d6 @@ -11,7 +11,7 @@ OPENJDK_CHANGESET = d39d0c08731a CORBA_SHA256SUM = 4c6db5299947c3ed11a7f72da55a3cd89197c143f10d77c75036aa2f2cf296a6 -HOTSPOT_SHA256SUM = 24da70ad4f2902269e0bb3a1a693dd15dfe1906c6f8019368be704915bccdb54 +HOTSPOT_SHA256SUM = 4ec39fddd8d5ff9e7e9e2dfeb4fff37c26e84c1aaa9a3f3953e4bedb00bc6713 JAXP_SHA256SUM = a1a5c6b2671f83d4675f9ba25013c6a16a4cf4d1040fcd2ff4143c92bd5496a3 JAXWS_SHA256SUM = 8fe84a61142d579487bee98133fc26e57aedb97f781dc925ad3803aa40f5c061 JDK_SHA256SUM = 564e9c9f7d6335d8fe221389893462dbb3daf4a20d9e75ffa37e9c8bbd7687be From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 07:33:09 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 14:33:09 +0000 Subject: [Bug 695] New: [TRACKER] IcedTea7 1.14 Release Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=695 Summary: [TRACKER] IcedTea7 1.14 Release Product: IcedTea Version: 7-hg Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: IcedTea7 AssignedTo: gnu_andrew at member.fsf.org ReportedBy: gnu_andrew at member.fsf.org CC: unassigned at icedtea.classpath.org Depends on: 694 Metabug for issues blocking the 1.14 release of IcedTea7. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 07:33:09 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 14:33:09 +0000 Subject: [Bug 694] ZeroVM fails to build from source In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=694 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |695 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 07:33:43 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 19 Apr 2011 14:33:43 +0000 Subject: [Bug 695] [TRACKER] IcedTea7 1.14 Release In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=695 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From andrew at icedtea.classpath.org Tue Apr 19 07:35:29 2011 From: andrew at icedtea.classpath.org (andrew at icedtea.classpath.org) Date: Tue, 19 Apr 2011 14:35:29 +0000 Subject: /hg/icedtea: Backport 2011/02/15 security fixes from main OpenJD... Message-ID: changeset 8f9c35e54e17 in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=8f9c35e54e17 author: Andrew John Hughes date: Tue Apr 19 15:35:23 2011 +0100 Backport 2011/02/15 security fixes from main OpenJDK7 tree. 2011-04-19 Andrew John Hughes * Makefile.am: (JDK_CHANGESET): Include security fixes from 2011/02/15. (JDK_SHA256SUM): Likewise. diffstat: ChangeLog | 7 +++++++ Makefile.am | 4 ++-- 2 files changed, 9 insertions(+), 2 deletions(-) diffs (35 lines): diff -r 41bcdf9bf8c1 -r 8f9c35e54e17 ChangeLog --- a/ChangeLog Tue Apr 19 15:22:08 2011 +0100 +++ b/ChangeLog Tue Apr 19 15:35:23 2011 +0100 @@ -1,3 +1,10 @@ +2011-04-19 Andrew John Hughes + + * Makefile.am: + (JDK_CHANGESET): Include security fixes + from 2011/02/15. + (JDK_SHA256SUM): Likewise. + 2011-04-19 Andrew John Hughes * Makefile.am: diff -r 41bcdf9bf8c1 -r 8f9c35e54e17 Makefile.am --- a/Makefile.am Tue Apr 19 15:22:08 2011 +0100 +++ b/Makefile.am Tue Apr 19 15:35:23 2011 +0100 @@ -6,7 +6,7 @@ HOTSPOT_CHANGESET = 4071da7ef7b3 JAXP_CHANGESET = b6f201c0649a JAXWS_CHANGESET = 4c04de31900b -JDK_CHANGESET = f6ac05b155d6 +JDK_CHANGESET = 6753b79d7bb5 LANGTOOLS_CHANGESET = 4659da7bff78 OPENJDK_CHANGESET = d39d0c08731a @@ -14,7 +14,7 @@ HOTSPOT_SHA256SUM = 4ec39fddd8d5ff9e7e9e2dfeb4fff37c26e84c1aaa9a3f3953e4bedb00bc6713 JAXP_SHA256SUM = a1a5c6b2671f83d4675f9ba25013c6a16a4cf4d1040fcd2ff4143c92bd5496a3 JAXWS_SHA256SUM = 8fe84a61142d579487bee98133fc26e57aedb97f781dc925ad3803aa40f5c061 -JDK_SHA256SUM = 564e9c9f7d6335d8fe221389893462dbb3daf4a20d9e75ffa37e9c8bbd7687be +JDK_SHA256SUM = 650922377d1e847c26e1ea7475a46ae6f8bac3ba7747a2c1467c7136d1b7b4d6 LANGTOOLS_SHA256SUM = 1df1bb1edd5f912405398c0024f8290f6a9030172dd1196c52e2c461769a1a07 OPENJDK_SHA256SUM = 937930cb6c3174f8bdbf3d0034832fbde539fd62591087f1d6fcec695ed20519 From doko at ubuntu.com Tue Apr 19 08:25:11 2011 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 19 Apr 2011 17:25:11 +0200 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> Message-ID: <4DADA957.8050004@ubuntu.com> plus the format for the /etc/lsb-release file is not part of the lsb spec. A proposal to either define an API to this information, or to document the format of this file didn't find much enthusiasm on the LSB ML. So I would like to stay with the current approch, and read the file if available. Matthias From dlila at redhat.com Tue Apr 19 08:28:18 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 19 Apr 2011 11:28:18 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <1292960503.46884.1303182178480.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <207593629.572776.1303226898061.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Can you replace this: > - String rStr = value.substring(cacheDir.length()); > + String rStr = file.getPath().substring(cacheDir.length()); > rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1)); > + long len = file.length(); with String rStr = cacheDir + File.separatorChar + CacheLRUWrapper.getIdForCacheFile(value); We already have the id extraction logic encapsulated in a function. There's no need to re-implement it in here (but this require some visibility changes. Maybe move getIdForCacheFile to CacheUtil?). > + curSize += len; > keep.add(value.substring(rStr.length())); > keep.add(rStr); // We can just use the same map, since these two things are disjoint with each other. Can you please introduce a new Set? I understand that they're disjoint, but it's still clearer and closer to what we want to have two sets: one for use in removeUntracked, and one for use in cleanCache. That way correctness would be obvious. This way the reader has to think about tricky corner cases. Thank you, Denis. ----- Original Message ----- > Hello, > > This patch will ensure the cache size will remain at most the size > specified in the user's deployment's properties file. > > This is executed only at jvm shutdown of the plugin and/or javaws. > > Questions? Comments? Concerns? > > Regards, > Andrew From avg at icyb.net.ua Tue Apr 19 08:44:08 2011 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue, 19 Apr 2011 18:44:08 +0300 Subject: firefox 4: problem with NPN_GetURL target=_self Message-ID: <4DADADC8.7010404@icyb.net.ua> [sorry for the cross-post but the issue at hand seems to be of dual nature] I observe a particular problem with Firefox 4 and IcedTea Java plugin. The issue can be described in simple terms as follows: - the plugin calls the browser via NPN_GetURL(target=_self) [because that's what a Java applet instructs it to do] - the browser makes a "nested" call back to the plugin via NPP_GetValue(NPPVpluginScriptableNPObject) - because of the peculiarities of the plugin implementation it gets stuck in this nested call until its internal timeout is reached [*] Now, the problem could be simply attributed to that peculiarity and the case would be solved for Firefox. But not quite yet. The same plugin with the same applet work without the problem with Firefox 3 and other browsers. I see one difference in the behavior: those browsers call NPP_Destroy in response to NPN_GetURL(target=_self). I guess that that makes sense because of the target=_self. [*] The way IcedTea uses glib channels for communication with Java process (applet runner) via named pipes precludes "recursive" communication - while a channel callback is running its channel seems to be excluded from being polled in the glib main loop. Thank you in advance for any help / insights. -- Andriy Gapon From asu at redhat.com Tue Apr 19 09:10:30 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 19 Apr 2011 12:10:30 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <207593629.572776.1303226898061.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <714504167.61132.1303229430757.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Denis Lila" > To: "Andrew Su" > Cc: "IcedTea" > Sent: Tuesday, April 19, 2011 11:28:18 AM > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > Can you replace this: > > > - String rStr = value.substring(cacheDir.length()); > > + String rStr = file.getPath().substring(cacheDir.length()); > > rStr = cacheDir + rStr.substring(0, > > rStr.indexOf(File.separatorChar, 1)); > > + long len = file.length(); > > with > > String rStr = cacheDir + File.separatorChar + > CacheLRUWrapper.getIdForCacheFile(value); > > We already have the id extraction logic encapsulated in a function. > There's no need to re-implement it in here (but this require some > visibility changes. Maybe move getIdForCacheFile to CacheUtil?). I think this should be in its own patch for refactoring, not related to handling cache size. > > > > + curSize += len; > > keep.add(value.substring(rStr.length())); > > keep.add(rStr); // We can just use the same > > map, since these two things are disjoint > > with each other. > > Can you please introduce a new Set? I understand that > they're disjoint, but it's still clearer and closer to what we > want to have two sets: one for use in removeUntracked, and > one for use in cleanCache. > That way correctness would be obvious. This way the reader > has to think about tricky corner cases. Same as above, should be done in another patch for refactoring. --snip-- Cheers, Andrew From dlila at redhat.com Tue Apr 19 09:22:15 2011 From: dlila at redhat.com (Denis Lila) Date: Tue, 19 Apr 2011 12:22:15 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <714504167.61132.1303229430757.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <722783932.573961.1303230135705.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > I think this should be in its own patch for refactoring, not related > to handling cache size. Hm, ok, sure. I'm ok with the patch then (as long as keep.contains(rStr) in the if statement is fixed as we discussed on irc). Regards, Denis. ----- Original Message ----- > ----- Original Message ----- > > From: "Denis Lila" > > To: "Andrew Su" > > Cc: "IcedTea" > > Sent: Tuesday, April 19, 2011 11:28:18 AM > > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > > Can you replace this: > > > > > - String rStr = value.substring(cacheDir.length()); > > > + String rStr = file.getPath().substring(cacheDir.length()); > > > rStr = cacheDir + rStr.substring(0, > > > rStr.indexOf(File.separatorChar, 1)); > > > + long len = file.length(); > > > > with > > > > String rStr = cacheDir + File.separatorChar + > > CacheLRUWrapper.getIdForCacheFile(value); > > > > We already have the id extraction logic encapsulated in a function. > > There's no need to re-implement it in here (but this require some > > visibility changes. Maybe move getIdForCacheFile to CacheUtil?). > > > > > > > > > + curSize += len; > > > keep.add(value.substring(rStr.length())); > > > keep.add(rStr); // We can just use the > > > same > > > map, since these two things are disjoint > > > with each other. > > > > Can you please introduce a new Set? I understand that > > they're disjoint, but it's still clearer and closer to what we > > want to have two sets: one for use in removeUntracked, and > > one for use in cleanCache. > > That way correctness would be obvious. This way the reader > > has to think about tricky corner cases. > > Same as above, should be done in another patch for refactoring. > > --snip-- > > Cheers, > Andrew From dbhole at redhat.com Tue Apr 19 09:32:08 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 19 Apr 2011 12:32:08 -0400 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <4DADADC8.7010404@icyb.net.ua> References: <4DADADC8.7010404@icyb.net.ua> Message-ID: <20110419163208.GB15825@redhat.com> * Andriy Gapon [2011-04-19 11:45]: > > [sorry for the cross-post but the issue at hand seems to be of dual nature] > > I observe a particular problem with Firefox 4 and IcedTea Java plugin. > The issue can be described in simple terms as follows: > - the plugin calls the browser via NPN_GetURL(target=_self) [because that's what a > Java applet instructs it to do] > - the browser makes a "nested" call back to the plugin via > NPP_GetValue(NPPVpluginScriptableNPObject) > - because of the peculiarities of the plugin implementation it gets stuck in this > nested call until its internal timeout is reached [*] > > Now, the problem could be simply attributed to that peculiarity and the case would > be solved for Firefox. But not quite yet. > > The same plugin with the same applet work without the problem with Firefox 3 and > other browsers. > I see one difference in the behavior: those browsers call NPP_Destroy in response > to NPN_GetURL(target=_self). I guess that that makes sense because of the > target=_self. > > [*] The way IcedTea uses glib channels for communication with Java process (applet > runner) via named pipes precludes "recursive" communication - while a channel > callback is running its channel seems to be excluded from being polled in the glib > main loop. > Which version of Firefox are you using? I tried the above scenario on FF 4.0 in Fedora 15 and saw no recursive calls. Having JS call a Java method which then calls NPN_GetURL (via AppletContext.showDocument()) worked fine for me. Cheers, Deepak > Thank you in advance for any help / insights. > > -- > Andriy Gapon From avg at icyb.net.ua Tue Apr 19 09:43:22 2011 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue, 19 Apr 2011 19:43:22 +0300 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <20110419163208.GB15825@redhat.com> References: <4DADADC8.7010404@icyb.net.ua> <20110419163208.GB15825@redhat.com> Message-ID: <4DADBBAA.1050902@icyb.net.ua> on 19/04/2011 19:32 Deepak Bhole said the following: > Which version of Firefox are you using? I tried the above scenario on FF > 4.0 in Fedora 15 and saw no recursive calls. I have Mozilla/5.0 (X11; FreeBSD amd64; rv:2.0) Gecko/20100101 Firefox/4.0. > Having JS call a Java method which then calls NPN_GetURL (via > AppletContext.showDocument()) worked fine for me. Just to double-check, you used showDocument(url, "_self") ? -- Andriy Gapon From asu at redhat.com Tue Apr 19 09:44:52 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 19 Apr 2011 12:44:52 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <20110419141437.GA15825@redhat.com> Message-ID: <286762532.61987.1303231492914.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Deepak Bhole" > To: "Andrew Su" > Cc: "IcedTea" > Sent: Tuesday, April 19, 2011 10:14:37 AM > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > * Andrew Su [2011-04-19 09:46]: > > > > > > > > > > > > When I said root directory, I meant it as in the unique folder to > > the item. > > Such as "/home/user1/.icedtea/cache/3" > > > > Okay. That will nuke everything in the cache from existing (current > format) cache dirs, but it is okay as that cache will never get used > anyway. > > > > > > > > > > > + long len = file.length(); > > > > > > > > - if (delete || keep.contains(rStr)) { > > > > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > > > > > > > > > maxSize) || keep.contains(rStr)) { > > > > > > Can you clarify the logic here (in a comment as well) please? > > > > > > 1. if delete == true, delete .... this is OK > > > > > > 2. if !file.isFile() .... would getLRUSortedEntries() ever return > > > a > > > dir? > > > > No, and it shouldn't, but let's say, directory was created but the > > actual item doesn't exist. If the item wasn't marked for deletion > > we'll have an empty folder lying around, should get rid of it. > > (This seems to go with previous patch more, missed this case) > > > > Fair enough. > > > > > > > 3. (maxSize >= 0 && curSize + len > maxSize) ... okay, sounds > > > reasonable, this is current behaviour > > > > > > 4. keep.contains(rStr) ... the else part of that block adds rStr > > > to > > > keep. Can there be a case where it shows up again during the > > > iteration? > > > > Nope, it doesn't the second add to keep is for use with > > removeUntrackedDirectories() > > Cheers, > > Okay. > > One last thing that just came to mind.. if I accidentally specify > $HOME > as the cachedir with size < sizeof($HOME), won't this patch nuke all > of it? Yup it would, but that fix should be separate from this, as that issue is also affected by calling clearcache from javaws. + in response to http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013708.html I have attached an updated version of the patch which correctly checks for the right string. (Even though it won't matter -for now- since both these entries will be in 'keep'). Attched patch has the change specified above. Cheers, Andrew --snip-- -------------- next part -------------- A non-text attachment was scrubbed... Name: patch2.patch Type: text/x-patch Size: 3466 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110419/464db1f9/patch2.patch From dbhole at redhat.com Tue Apr 19 09:55:36 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 19 Apr 2011 12:55:36 -0400 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <4DADBBAA.1050902@icyb.net.ua> References: <4DADADC8.7010404@icyb.net.ua> <20110419163208.GB15825@redhat.com> <4DADBBAA.1050902@icyb.net.ua> Message-ID: <20110419165535.GC15825@redhat.com> * Andriy Gapon [2011-04-19 12:43]: > on 19/04/2011 19:32 Deepak Bhole said the following: > > Which version of Firefox are you using? I tried the above scenario on FF > > 4.0 in Fedora 15 and saw no recursive calls. > > I have Mozilla/5.0 (X11; FreeBSD amd64; rv:2.0) Gecko/20100101 Firefox/4.0. > > > Having JS call a Java method which then calls NPN_GetURL (via > > AppletContext.showDocument()) worked fine for me. > > Just to double-check, you used showDocument(url, "_self") ? > Yes, this is the code I used: $ cat Test.java import java.applet.Applet; import java.awt.Graphics; import java.net.URL; public class Test extends Applet { public void changePage(String url) { System.err.println("Attempting to go to: " + url); try { getAppletContext().showDocument(new URL(url), "_self"); } catch (Exception e) { e.printStackTrace(); } } } $ cat Test.html NPN_GetURL Test

Cheers, Deepak > -- > Andriy Gapon From avg at icyb.net.ua Tue Apr 19 10:09:10 2011 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue, 19 Apr 2011 20:09:10 +0300 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <20110419165535.GC15825@redhat.com> References: <4DADADC8.7010404@icyb.net.ua> <20110419163208.GB15825@redhat.com> <4DADBBAA.1050902@icyb.net.ua> <20110419165535.GC15825@redhat.com> Message-ID: <4DADC1B6.5060100@icyb.net.ua> on 19/04/2011 19:55 Deepak Bhole said the following: > * Andriy Gapon [2011-04-19 12:43]: >> on 19/04/2011 19:32 Deepak Bhole said the following: >>> Which version of Firefox are you using? I tried the above scenario on FF >>> 4.0 in Fedora 15 and saw no recursive calls. >> >> I have Mozilla/5.0 (X11; FreeBSD amd64; rv:2.0) Gecko/20100101 Firefox/4.0. >> >>> Having JS call a Java method which then calls NPN_GetURL (via >>> AppletContext.showDocument()) worked fine for me. >> >> Just to double-check, you used showDocument(url, "_self") ? >> > > Yes, this is the code I used: Oh, hmm, indeed - I can not reproduce the problem with this simple test case. I wonder what the original problematic applet does there - unfortunately I can't provide an easy URL to it as it is within a banking website behind authentication. I will try to come up with sample code that reproduces the behavior. -- Andriy Gapon From dbhole at redhat.com Tue Apr 19 10:20:10 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 19 Apr 2011 13:20:10 -0400 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <4DADC1B6.5060100@icyb.net.ua> References: <4DADADC8.7010404@icyb.net.ua> <20110419163208.GB15825@redhat.com> <4DADBBAA.1050902@icyb.net.ua> <20110419165535.GC15825@redhat.com> <4DADC1B6.5060100@icyb.net.ua> Message-ID: <20110419172010.GD15825@redhat.com> * Andriy Gapon [2011-04-19 13:09]: > on 19/04/2011 19:55 Deepak Bhole said the following: > > * Andriy Gapon [2011-04-19 12:43]: > >> on 19/04/2011 19:32 Deepak Bhole said the following: > >>> Which version of Firefox are you using? I tried the above scenario on FF > >>> 4.0 in Fedora 15 and saw no recursive calls. > >> > >> I have Mozilla/5.0 (X11; FreeBSD amd64; rv:2.0) Gecko/20100101 Firefox/4.0. > >> > >>> Having JS call a Java method which then calls NPN_GetURL (via > >>> AppletContext.showDocument()) worked fine for me. > >> > >> Just to double-check, you used showDocument(url, "_self") ? > >> > > > > Yes, this is the code I used: > > Oh, hmm, indeed - I can not reproduce the problem with this simple test case. > I wonder what the original problematic applet does there - unfortunately I can't > provide an easy URL to it as it is within a banking website behind authentication. > I will try to come up with sample code that reproduces the behavior. > That'd be great, thanks! Cheers, Deepak > -- > Andriy Gapon From avg at icyb.net.ua Tue Apr 19 10:35:25 2011 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue, 19 Apr 2011 20:35:25 +0300 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <20110419172010.GD15825@redhat.com> References: <4DADADC8.7010404@icyb.net.ua> <20110419163208.GB15825@redhat.com> <4DADBBAA.1050902@icyb.net.ua> <20110419165535.GC15825@redhat.com> <4DADC1B6.5060100@icyb.net.ua> <20110419172010.GD15825@redhat.com> Message-ID: <4DADC7DD.4080903@icyb.net.ua> on 19/04/2011 20:20 Deepak Bhole said the following: > > That'd be great, thanks! OK, just got it - geturl has to be initiated from the applet itself. Here is the updated example: http://people.freebsd.org/~avg/java_test/Test.html (http://people.freebsd.org/~avg/java_test/ is browsable) Please compare behavior of: 1. pressing the html button 2. pressing first the html button then navigating back and then the applet button 3. pressing only the applet button (e.g. after force reloading the page) Thanks! -- Andriy Gapon From dbhole at redhat.com Tue Apr 19 11:09:06 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 19 Apr 2011 14:09:06 -0400 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <4DADC7DD.4080903@icyb.net.ua> References: <4DADADC8.7010404@icyb.net.ua> <20110419163208.GB15825@redhat.com> <4DADBBAA.1050902@icyb.net.ua> <20110419165535.GC15825@redhat.com> <4DADC1B6.5060100@icyb.net.ua> <20110419172010.GD15825@redhat.com> <4DADC7DD.4080903@icyb.net.ua> Message-ID: <20110419180905.GE15825@redhat.com> * Andriy Gapon [2011-04-19 13:35]: > on 19/04/2011 20:20 Deepak Bhole said the following: > > > > That'd be great, thanks! > > OK, just got it - geturl has to be initiated from the applet itself. > Here is the updated example: > http://people.freebsd.org/~avg/java_test/Test.html > (http://people.freebsd.org/~avg/java_test/ is browsable) > > Please compare behavior of: > 1. pressing the html button > 2. pressing first the html button then navigating back and then the applet button > 3. pressing only the applet button (e.g. after force reloading the page) > There appears to be an odd race condition happening in Firefox code. If I do #3 normally, it freezes. If I open the browser via gdb and try it though, it works fine. Anyway... Though a bug in Firefox, this is a shortcoming in the plugin as well. Unfortunately it is not one that can be easily mitigated with the current plugin design. The LiveConnect engine (that handles JS <-> Java communications) can handle recursive calls. But the part that handles other (non LiveConnect) requests (geturl, setstatus, etc.) is not designed to handle recursions as there should never be a need for it. The GetJavaObject request being made by NPN_GetURL is rather odd as the latter is a non-liveconnect functionality, yet it is making a liveconnect related call (GetJavaObject). I will look into recursion handling, but it is unlikely to happen soon as it will be a fair bit of change. In the mean time, I believe it would be worthwhile to pursue this on Mozilla side as well, since it's code is definitely doing something odd. Cheers, Deepak > Thanks! > -- > Andriy Gapon From avg at icyb.net.ua Tue Apr 19 11:11:41 2011 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue, 19 Apr 2011 21:11:41 +0300 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <20110419180905.GE15825@redhat.com> References: <4DADADC8.7010404@icyb.net.ua> <20110419163208.GB15825@redhat.com> <4DADBBAA.1050902@icyb.net.ua> <20110419165535.GC15825@redhat.com> <4DADC1B6.5060100@icyb.net.ua> <20110419172010.GD15825@redhat.com> <4DADC7DD.4080903@icyb.net.ua> <20110419180905.GE15825@redhat.com> Message-ID: <4DADD05D.5020206@icyb.net.ua> on 19/04/2011 21:09 Deepak Bhole said the following: > * Andriy Gapon [2011-04-19 13:35]: >> on 19/04/2011 20:20 Deepak Bhole said the following: >>> >>> That'd be great, thanks! >> >> OK, just got it - geturl has to be initiated from the applet itself. >> Here is the updated example: >> http://people.freebsd.org/~avg/java_test/Test.html >> (http://people.freebsd.org/~avg/java_test/ is browsable) >> >> Please compare behavior of: >> 1. pressing the html button >> 2. pressing first the html button then navigating back and then the applet button >> 3. pressing only the applet button (e.g. after force reloading the page) >> > > There appears to be an odd race condition happening in Firefox code. If > I do #3 normally, it freezes. If I open the browser via gdb and try it > though, it works fine. Anyway... > > Though a bug in Firefox, this is a shortcoming in the plugin as well. > Unfortunately it is not one that can be easily mitigated with the > current plugin design. > > The LiveConnect engine (that handles JS <-> Java communications) can > handle recursive calls. But the part that handles other (non > LiveConnect) requests (geturl, setstatus, etc.) is not designed to > handle recursions as there should never be a need for it. > > The GetJavaObject request being made by NPN_GetURL is rather odd as the > latter is a non-liveconnect functionality, yet it is making a > liveconnect related call (GetJavaObject). I will look into recursion > handling, but it is unlikely to happen soon as it will be a fair bit of > change. In the mean time, I believe it would be worthwhile to pursue > this on Mozilla side as well, since it's code is definitely doing > something odd. Yes, I completely agree on all accounts. Thank you for the review! I will try to pursue this further with the mozilla folks. -- Andriy Gapon From avg at icyb.net.ua Tue Apr 19 11:14:29 2011 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue, 19 Apr 2011 21:14:29 +0300 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <4DADCF06.8080803@smedbergs.us> References: <4DADADC8.7010404@icyb.net.ua> <4DADCF06.8080803@smedbergs.us> Message-ID: <4DADD105.30103@icyb.net.ua> on 19/04/2011 21:05 Benjamin Smedberg said the following: > It sounds like this could possibly be related to the plugin process implementation > in Firefox 4 I am not if this is really so... IcedTea plugin itself spawns a JVM process to handle applet byte code. I am not sure if that has any relation to what Firefox does for/on/about plugins. -- Andriy Gapon From omajid at redhat.com Tue Apr 19 12:01:42 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 19 Apr 2011 15:01:42 -0400 Subject: JSR292 fix for IcedTea7 Message-ID: <4DADDC16.1070107@redhat.com> Hi, The JSR292 changesets recently backported to IcedTea7 break the build since they rely on newer symbols. The JSR292 fixes are based on a newer build than b130. The newer builds use java_lang_invoke_* symbols instead of the older java_dyn_* and sun_dyn_* in b130. The attached patch renames the symbols so zero can be built. I am not sure if the best place to add this is the icedtea7 repo (at icedtea.classpath.org) or the icedtea7 forest (at openjdk.java.net). Once we move past b130 to the latest builds, this patch would have to be dropped/reverted. Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: zero-java-dyn.patch Type: text/x-patch Size: 10735 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110419/c5b3606b/zero-java-dyn.patch From omajid at redhat.com Tue Apr 19 12:06:25 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 19 Apr 2011 15:06:25 -0400 Subject: [patch] update patches/boot/gest_gamma.patch for shark Message-ID: <4DADDD31.70305@redhat.com> Hi, The attached patch disables the gamma tests when a bootstrapped sharked is being built. Without this patch gamma cant find libjava.so which will cause the build to fail. Okay to commit? Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea7-shark-gamma.patch Type: text/x-patch Size: 1088 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110419/53853b53/icedtea7-shark-gamma.patch From omajid at icedtea.classpath.org Tue Apr 19 13:38:41 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Tue, 19 Apr 2011 20:38:41 +0000 Subject: /hg/icedtea: Update patches/boot/test_gamma.patch to skip test_g... Message-ID: changeset bb4033154745 in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=bb4033154745 author: Omair Majid date: Tue Apr 19 16:38:18 2011 -0400 Update patches/boot/test_gamma.patch to skip test_gamma for Shark diffstat: ChangeLog | 4 ++++ patches/boot/test_gamma.patch | 10 +++++++++- 2 files changed, 13 insertions(+), 1 deletions(-) diffs (35 lines): diff -r 8f9c35e54e17 -r bb4033154745 ChangeLog --- a/ChangeLog Tue Apr 19 15:35:23 2011 +0100 +++ b/ChangeLog Tue Apr 19 16:38:18 2011 -0400 @@ -1,3 +1,7 @@ +2011-04-19 Omair Majid + + * patches/boot/test_gamma.patch: Skip test_gamma for shark too. + 2011-04-19 Andrew John Hughes * Makefile.am: diff -r 8f9c35e54e17 -r bb4033154745 patches/boot/test_gamma.patch --- a/patches/boot/test_gamma.patch Tue Apr 19 15:35:23 2011 +0100 +++ b/patches/boot/test_gamma.patch Tue Apr 19 16:38:18 2011 -0400 @@ -1,7 +1,7 @@ diff -Nru ../openjdk.orig/openjdk-boot/hotspot/make/linux/Makefile openjdk-boot/hotspot/make/linux/Makefile --- ../openjdk.orig/openjdk-boot/hotspot/make/linux/Makefile 2009-10-30 17:37:07.000000000 +0000 +++ openjdk-boot/hotspot/make/linux/Makefile 2009-10-30 17:45:40.000000000 +0000 -@@ -287,35 +287,30 @@ +@@ -287,42 +287,36 @@ $(TARGETS_C2): $(SUBDIRS_C2) cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && $(MAKE) $(MFLAGS) @@ -37,3 +37,11 @@ ifdef INSTALL cd $(OSNAME)_$(VARIANTARCH)_zero/$(patsubst %zero,%,$@) && $(MAKE) $(MFLAGS) install endif + + $(TARGETS_SHARK): $(SUBDIRS_SHARK) + cd $(OSNAME)_$(VARIANTARCH)_shark/$(patsubst %shark,%,$@) && $(MAKE) $(MFLAGS) +- cd $(OSNAME)_$(VARIANTARCH)_shark/$(patsubst %shark,%,$@) && ./test_gamma + ifdef INSTALL + cd $(OSNAME)_$(VARIANTARCH)_shark/$(patsubst %shark,%,$@) && $(MAKE) $(MFLAGS) install + endif + From asu at redhat.com Tue Apr 19 14:18:29 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 19 Apr 2011 17:18:29 -0400 (EDT) Subject: [rfc][icedtea-web]: Tell lruHandler to store after modifying. In-Reply-To: <270395771.68980.1303247849976.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1671915997.68988.1303247909382.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hi, This patch is to add the missing lruHandler.store() line when we update the access time for the jar file. Without it, it causes duplicate entries to show up.. and becomes inconsistent when running with another javaws/plugin instance. Ok to push? Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: forgot_to_save.patch Type: text/x-patch Size: 511 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110419/9e413029/forgot_to_save.patch From asu at redhat.com Tue Apr 19 14:30:08 2011 From: asu at redhat.com (Andrew Su) Date: Tue, 19 Apr 2011 17:30:08 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <20110419141437.GA15825@redhat.com> Message-ID: <969152949.69239.1303248608497.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Deepak Bhole" > To: "Andrew Su" > Cc: "IcedTea" > Sent: Tuesday, April 19, 2011 10:14:37 AM > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > * Andrew Su [2011-04-19 09:46]: > > > > > > > > > > > > When I said root directory, I meant it as in the unique folder to > > the item. > > Such as "/home/user1/.icedtea/cache/3" > > > > Okay. That will nuke everything in the cache from existing (current > format) cache dirs, but it is okay as that cache will never get used > anyway. > > > > > > > > > > > + long len = file.length(); > > > > > > > > - if (delete || keep.contains(rStr)) { > > > > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > > > > > > > > > maxSize) || keep.contains(rStr)) { > > > > > > Can you clarify the logic here (in a comment as well) please? > > > > > > 1. if delete == true, delete .... this is OK > > > > > > 2. if !file.isFile() .... would getLRUSortedEntries() ever return > > > a > > > dir? > > > > No, and it shouldn't, but let's say, directory was created but the > > actual item doesn't exist. If the item wasn't marked for deletion > > we'll have an empty folder lying around, should get rid of it. > > (This seems to go with previous patch more, missed this case) > > > > Fair enough. > > > > > > > 3. (maxSize >= 0 && curSize + len > maxSize) ... okay, sounds > > > reasonable, this is current behaviour > > > > > > 4. keep.contains(rStr) ... the else part of that block adds rStr > > > to > > > keep. Can there be a case where it shows up again during the > > > iteration? > > > > Nope, it doesn't the second add to keep is for use with > > removeUntrackedDirectories() > > Cheers, > > Okay. > > One last thing that just came to mind.. if I accidentally specify > $HOME > as the cachedir with size < sizeof($HOME), won't this patch nuke all > of it? Here's an updated patch which will also remove the items extracted by activateJar() and it will also only remove items we have a record of. With the exception of the http and https folder which exist with the old cache implementation. This would be less destructive if there happened to be a config error and maybe pointed cache to a directory already containing these two folders. -- snip -- Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: ajar_remove_enforce.patch Type: text/x-patch Size: 5458 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110419/3a8a1c2b/ajar_remove_enforce.patch From dbhole at redhat.com Tue Apr 19 15:29:01 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Tue, 19 Apr 2011 18:29:01 -0400 Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <969152949.69239.1303248608497.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <20110419141437.GA15825@redhat.com> <969152949.69239.1303248608497.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110419222901.GH15825@redhat.com> * Andrew Su [2011-04-19 17:30]: > > > ----- Original Message ----- > + } catch (IOException e1) { > + e1.printStackTrace(); Why e1 and not e? Rest looks fine to me. Okay from me after above e1 -> e change. Cheers, Deepak > + } > + } > + } > } > } else { > lruHandler.removeEntry(key); > @@ -560,20 +600,26 @@ > } > lruHandler.store(); > > - removeUntrackedDirectories(keep); > + /* > + * FIXME: if cacheDir is for example $USER_HOME and they have a folder called http > + * and/or https. These would get removed. > + */ > + remove.add(cacheDir + File.separator + "http"); > + remove.add(cacheDir + File.separator + "https"); > + > + remove.removeAll(keep); > + > + removeSetOfDirectories(remove); > + > } > } > > - private static void removeUntrackedDirectories(Set keep) { > - File temp = new File(cacheDir); > - // Remove all folder not listed in keep. > - for (File f : temp.listFiles()) { > - if (f.isDirectory() && !keep.contains(f.getPath())) { > - try { > - FileUtils.recursiveDelete(f, f); > - } catch (IOException e) { > - e.printStackTrace(); > - } > + private static void removeSetOfDirectories(Set remove) { > + for (String s : remove) { > + File f = new File(s); > + try { > + FileUtils.recursiveDelete(f, f); > + } catch (IOException e) { > } > } > } From ahughes at redhat.com Tue Apr 19 18:45:42 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 02:45:42 +0100 Subject: JSR292 fix for IcedTea7 In-Reply-To: <4DADDC16.1070107@redhat.com> References: <4DADDC16.1070107@redhat.com> Message-ID: <20110420014542.GI29985@rivendell.middle-earth.co.uk> On 15:01 Tue 19 Apr , Omair Majid wrote: > Hi, > > The JSR292 changesets recently backported to IcedTea7 break the build > since they rely on newer symbols. The JSR292 fixes are based on a newer > build than b130. The newer builds use java_lang_invoke_* symbols instead > of the older java_dyn_* and sun_dyn_* in b130. The attached patch > renames the symbols so zero can be built. > > I am not sure if the best place to add this is the icedtea7 repo (at > icedtea.classpath.org) or the icedtea7 forest (at openjdk.java.net). > Once we move past b130 to the latest builds, this patch would have to be > dropped/reverted. > > Cheers, > Omair I'm in the process of updating to the b137 release to solve this instead. I'd rather this than we have to modify this code, and b130 didn't seem so good anyway (despite Oracle calling it out as Developer Preview) once I realised the latest security updates weren't in it. I'll post to the list once this is done. In future, it would be nice if Zero/Shark updates weren't lagging so far behind mainstream HotSpot development. Thanks to Xerxes and Omair for testing and finding the required changesets to update this. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Apr 19 18:47:10 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 02:47:10 +0100 Subject: [patch] update patches/boot/gest_gamma.patch for shark In-Reply-To: <4DADDD31.70305@redhat.com> References: <4DADDD31.70305@redhat.com> Message-ID: <20110420014710.GJ29985@rivendell.middle-earth.co.uk> On 15:06 Tue 19 Apr , Omair Majid wrote: > Hi, > > The attached patch disables the gamma tests when a bootstrapped sharked > is being built. Without this patch gamma cant find libjava.so which will > cause the build to fail. Okay to commit? > > Cheers, > Omair Looks fine, except you're missing a ChangeLog :-) FYI: In general, for IcedTea7, bootstrap patches like this go in the IcedTea7 repository (as you've done here) while we try to add mainstream patches into the forest for easier maintenance. > diff -r 8f9c35e54e17 patches/boot/test_gamma.patch > --- a/patches/boot/test_gamma.patch Tue Apr 19 15:35:23 2011 +0100 > +++ b/patches/boot/test_gamma.patch Tue Apr 19 15:03:14 2011 -0400 > @@ -1,7 +1,7 @@ > diff -Nru ../openjdk.orig/openjdk-boot/hotspot/make/linux/Makefile openjdk-boot/hotspot/make/linux/Makefile > --- ../openjdk.orig/openjdk-boot/hotspot/make/linux/Makefile 2009-10-30 17:37:07.000000000 +0000 > +++ openjdk-boot/hotspot/make/linux/Makefile 2009-10-30 17:45:40.000000000 +0000 > -@@ -287,35 +287,30 @@ > +@@ -287,42 +287,36 @@ > > $(TARGETS_C2): $(SUBDIRS_C2) > cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && $(MAKE) $(MFLAGS) > @@ -37,3 +37,11 @@ > ifdef INSTALL > cd $(OSNAME)_$(VARIANTARCH)_zero/$(patsubst %zero,%,$@) && $(MAKE) $(MFLAGS) install > endif > + > + $(TARGETS_SHARK): $(SUBDIRS_SHARK) > + cd $(OSNAME)_$(VARIANTARCH)_shark/$(patsubst %shark,%,$@) && $(MAKE) $(MFLAGS) > +- cd $(OSNAME)_$(VARIANTARCH)_shark/$(patsubst %shark,%,$@) && ./test_gamma > + ifdef INSTALL > + cd $(OSNAME)_$(VARIANTARCH)_shark/$(patsubst %shark,%,$@) && $(MAKE) $(MFLAGS) install > + endif > + -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Tue Apr 19 18:56:52 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 02:56:52 +0100 Subject: IcedTea7 build failed for 2cd959df7e7a In-Reply-To: References: Message-ID: <20110420015650.GM29985@rivendell.middle-earth.co.uk> On 17:37 Mon 18 Apr , Mark Wielaard wrote: > The current IcedTea build fails. > snip... > Checking patches/cacao/launcher.patch > 1 out of 3 hunks FAILED -- saving rejects to file openjdk/jdk/src/share/bin/java.c.rej > ERROR patch patches/cacao/launcher.patch FAILED! > WARNING make clean-patch before retrying a fix > make: *** [stamps/patch.stamp] Error 2 I'm not seeing this. Is this because these buildbots enable CACAO? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From bugzilla-daemon at icedtea.classpath.org Tue Apr 19 19:00:48 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 20 Apr 2011 02:00:48 +0000 Subject: [Bug 639] Shark fails with hs20 In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=639 --- Comment #6 from Andrew John Hughes 2011-04-20 02:00:48 --- Yes, it's an LD_LIBRARY_PATH issue. But this is a system install of LLVM. Things should work out of the box IMHO, especially as we tell the build where LLVM is already. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From mark at klomp.org Wed Apr 20 00:02:00 2011 From: mark at klomp.org (Mark Wielaard) Date: Wed, 20 Apr 2011 09:02:00 +0200 Subject: IcedTea7 build failed for 2cd959df7e7a In-Reply-To: <20110420015650.GM29985@rivendell.middle-earth.co.uk> References: <20110420015650.GM29985@rivendell.middle-earth.co.uk> Message-ID: <1303282920.11416.11.camel@springer.wildebeest.org> On Wed, 2011-04-20 at 02:56 +0100, Dr Andrew John Hughes wrote: > On 17:37 Mon 18 Apr , Mark Wielaard wrote: > > The current IcedTea build fails. > > > snip... > > > Checking patches/cacao/launcher.patch > > 1 out of 3 hunks FAILED -- saving rejects to file openjdk/jdk/src/share/bin/java.c.rej > > ERROR patch patches/cacao/launcher.patch FAILED! > > WARNING make clean-patch before retrying a fix > > make: *** [stamps/patch.stamp] Error 2 > > I'm not seeing this. Is this because these buildbots enable CACAO? Yes it uses: (cd $ICEDTEA_DIR && ./autogen.sh \ && cd $ICEDTEA_BUILD_DIR \ && $ICEDTEA_DIR/configure \ --enable-nss \ --with-additional-vms=cacao,shark \ && make VERBOSE=true) 2>&1 | tee $BUILD_LOG_FILE See http://icedtea.classpath.org/hg/buildbot/file/tip/icedtea/build.sh Other builders also seem to fail currently. See e.g. http://builder.classpath.org/icedtea/buildbot/builders/icedtea7-squeeze-x86_64-full/builds/10 which has the full configure step in its logs (step 4). Cheers, Mark From avg at icyb.net.ua Tue Apr 19 08:36:38 2011 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue, 19 Apr 2011 18:36:38 +0300 Subject: firefox 4: problem with NPN_GetURL target=_self Message-ID: <4DADAC06.1070408@icyb.net.ua> [sorry for the cross-post but the issue at hand seems to be of dual nature] I observe a particular problem with Firefox 4 and IcedTea Java plugin. The issue can be described in simple terms as follows: - the plugin calls the browser via NPN_GetURL(target=_self) [because that's what a Java applet instructs it to do] - the browser makes a "nested" call back to the plugin via NPP_GetValue(NPPVpluginScriptableNPObject) - because of the peculiarities of the plugin implementation it gets stuck in this nested call until its internal timeout is reached [*] Now, the problem could be simply attributed to that peculiarity and the case would be solved for Firefox. But not quite yet. The same plugin with the same applet work without the problem with Firefox 3 and other browsers. I see one difference in the behavior: those browsers call NPP_Destroy in response to NPN_GetURL(target=_self). I guess that that makes sense because of the target=_self. [*] The way IcedTea uses glib channels for communication with Java process (applet runner) via named pipes precludes "recursive" communication - while a channel callback is running its channel seems to be excluded from being polled in the glib main loop. Thank you in advance for any help / insights. -- Andriy Gapon From benjamin at smedbergs.us Tue Apr 19 11:05:58 2011 From: benjamin at smedbergs.us (Benjamin Smedberg) Date: Tue, 19 Apr 2011 14:05:58 -0400 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <4DADADC8.7010404@icyb.net.ua> References: <4DADADC8.7010404@icyb.net.ua> Message-ID: <4DADCF06.8080803@smedbergs.us> On 4/19/2011 11:44 AM, Andriy Gapon wrote: > [sorry for the cross-post but the issue at hand seems to be of dual nature] > > I observe a particular problem with Firefox 4 and IcedTea Java plugin. > The issue can be described in simple terms as follows: > - the plugin calls the browser via NPN_GetURL(target=_self) [because that's what a > Java applet instructs it to do] > - the browser makes a "nested" call back to the plugin via > NPP_GetValue(NPPVpluginScriptableNPObject) It seems a bit odd that we are getting the scriptable object in this case, but in general plugins should expect to receive nested calls (except for NPP_Destroy) and be prepared to handle them. It sounds like this could possibly be related to the plugin process implementation in Firefox 4, but we turned that off for Java plugins because of persistent bugs, so it shouldn't be an issue. --BDS From Dmitry.Samersoff at oracle.com Wed Apr 20 02:34:52 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 20 Apr 2011 13:34:52 +0400 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <4DADA957.8050004@ubuntu.com> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DADA957.8050004@ubuntu.com> Message-ID: <4DAEA8BC.2030801@oracle.com> Matthias, Can't we just read /proc/version ? e.g.: Linux version 2.6.25-14.fc9.x86_64 (mockbuild@) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Thu May 1 06:06:21 EDT 2008 Linux version 2.6.38.2 (root at yoda) (gcc version 4.3.4 (Gentoo 4.3.4 p1.0, pie-10.1.5) ) #1 SMP PREEMPT Sat Apr 16 00:19:00 MSD 20 On 2011-04-19 19:25, Matthias Klose wrote: > plus the format for the /etc/lsb-release file is not part of the lsb > spec. A proposal to either define an API to this information, or to > document the format of this file didn't find much enthusiasm on the LSB > ML. So I would like to stay with the current approch, and read the file > if available. > > Matthias -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From doko at ubuntu.com Wed Apr 20 02:51:08 2011 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 20 Apr 2011 11:51:08 +0200 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <4DAEA8BC.2030801@oracle.com> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DADA957.8050004@ubuntu.com> <4DAEA8BC.2030801@oracle.com> Message-ID: <4DAEAC8C.8060901@ubuntu.com> No, that would be completely wrong. /proc/version tells you something about the running kernel, not about the distribution. On 04/20/2011 11:34 AM, Dmitry Samersoff wrote: > Matthias, > > Can't we just read /proc/version ? > > e.g.: > > Linux version 2.6.25-14.fc9.x86_64 (mockbuild@) (gcc version 4.3.0 20080428 (Red > Hat 4.3.0-8) (GCC) ) #1 SMP Thu May 1 06:06:21 EDT 2008 > > Linux version 2.6.38.2 (root at yoda) (gcc version 4.3.4 (Gentoo 4.3.4 p1.0, > pie-10.1.5) ) #1 SMP PREEMPT Sat Apr 16 00:19:00 MSD 20 > > > > On 2011-04-19 19:25, Matthias Klose wrote: >> plus the format for the /etc/lsb-release file is not part of the lsb >> spec. A proposal to either define an API to this information, or to >> document the format of this file didn't find much enthusiasm on the LSB >> ML. So I would like to stay with the current approch, and read the file >> if available. >> >> Matthias > > From xerxes at zafena.se Wed Apr 20 03:28:31 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Wed, 20 Apr 2011 12:28:31 +0200 Subject: RFC: PR690: Shark fails to JIT using hs20 Message-ID: <4DAEB54F.2060806@zafena.se> Hi the attached patches updates icedtea6-1.10 and icedtea6 trunk to make the Shark JIT work when using HotSpot 20 and later: Before: #Shark built against hs20 fails to JIT. icedtea6-shark/openjdk.build/j2sdk-image/bin/java -version java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.11pre+r0239a181c7a0+) (Ubuntu build 1.6.0_22-b22) OpenJDK Shark VM (build 20.0-b11, mixed mode) xerxes at xerxes-J464X:~/cm30$ ../icedtea6-shark/openjdk.build/j2sdk-image/bin/java CaffeineMarkEmbeddedApp Sieve score = 2648 (98) Loop score = 1746 (2017) Logic score = 2459 (0) String score = 4048 (708) Float score = 1836 (185) Method score = 1490 (166650) Overall score = 2238 After: xerxes at xerxes-J464X:~/cm30$ ../icedtea6-shark-hs/openjdk.build/j2sdk-image/binava -showversion CaffeineMarkEmbeddedApp java version "1.6.0_22" OpenJDK Runtime Environment (IcedTea6 1.11pre+r307d19e0cca0+) (Ubuntu build 1.6.0_22-b22) OpenJDK Shark VM (build 20.0-b11, mixed mode) Sieve score = 39462 (98) Loop score = 54003 (2017) Logic score = 71066 (0) String score = 26256 (708) Float score = 33218 (185) Method score = 21011 (166650) Overall score = 37487 I have tested these patches using the following three configurations: ../icedtea6-1.10/configure --enable-shark --disable-bootstrap --disable-docs --with-hotspot-build ../icedtea6/configure --enable-shark --disable-docs --disable-bootstrap ../icedtea6/configure --enable-shark --disable-bootstrap --disable-docs --with-hotspot-build Ok to push to IcedTea6-1.10 release branch? Ok to push to IcedTea6 trunk? Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-pr690-shark-jit-hs20.patch Type: text/x-patch Size: 5098 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/0daaf4b2/icedtea6-pr690-shark-jit-hs20.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-1.10-pr690-shark-jit-hs20.patch Type: text/x-patch Size: 5017 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/0daaf4b2/icedtea6-1.10-pr690-shark-jit-hs20.patch From Dmitry.Samersoff at oracle.com Wed Apr 20 04:23:34 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 20 Apr 2011 15:23:34 +0400 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <4DAEAC8C.8060901@ubuntu.com> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DADA957.8050004@ubuntu.com> <4DAEA8BC.2030801@oracle.com> <4DAEAC8C.8060901@ubuntu.com> Message-ID: <4DAEC236.2090706@oracle.com> Matthias, What is the purpose of this identification? -Dmitry On 2011-04-20 13:51, Matthias Klose wrote: > No, that would be completely wrong. /proc/version tells you something > about the running kernel, not about the distribution. > > On 04/20/2011 11:34 AM, Dmitry Samersoff wrote: >> Matthias, >> >> Can't we just read /proc/version ? >> >> e.g.: >> >> Linux version 2.6.25-14.fc9.x86_64 (mockbuild@) (gcc version 4.3.0 >> 20080428 (Red >> Hat 4.3.0-8) (GCC) ) #1 SMP Thu May 1 06:06:21 EDT 2008 >> >> Linux version 2.6.38.2 (root at yoda) (gcc version 4.3.4 (Gentoo 4.3.4 p1.0, >> pie-10.1.5) ) #1 SMP PREEMPT Sat Apr 16 00:19:00 MSD 20 >> >> >> >> On 2011-04-19 19:25, Matthias Klose wrote: >>> plus the format for the /etc/lsb-release file is not part of the lsb >>> spec. A proposal to either define an API to this information, or to >>> document the format of this file didn't find much enthusiasm on the LSB >>> ML. So I would like to stay with the current approch, and read the file >>> if available. >>> >>> Matthias >> >> > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From doko at ubuntu.com Wed Apr 20 04:31:43 2011 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 20 Apr 2011 13:31:43 +0200 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <4DAEC236.2090706@oracle.com> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DADA957.8050004@ubuntu.com> <4DAEA8BC.2030801@oracle.com> <4DAEAC8C.8060901@ubuntu.com> <4DAEC236.2090706@oracle.com> Message-ID: <4DAEC41F.6030700@ubuntu.com> To identify the distribution the VM runs on? But maybe I don't understand the question. Matthias On 04/20/2011 01:23 PM, Dmitry Samersoff wrote: > Matthias, > > What is the purpose of this identification? > > -Dmitry > > On 2011-04-20 13:51, Matthias Klose wrote: >> No, that would be completely wrong. /proc/version tells you something >> about the running kernel, not about the distribution. >> >> On 04/20/2011 11:34 AM, Dmitry Samersoff wrote: >>> Matthias, >>> >>> Can't we just read /proc/version ? >>> >>> e.g.: >>> >>> Linux version 2.6.25-14.fc9.x86_64 (mockbuild@) (gcc version 4.3.0 >>> 20080428 (Red >>> Hat 4.3.0-8) (GCC) ) #1 SMP Thu May 1 06:06:21 EDT 2008 >>> >>> Linux version 2.6.38.2 (root at yoda) (gcc version 4.3.4 (Gentoo 4.3.4 p1.0, >>> pie-10.1.5) ) #1 SMP PREEMPT Sat Apr 16 00:19:00 MSD 20 >>> >>> >>> >>> On 2011-04-19 19:25, Matthias Klose wrote: >>>> plus the format for the /etc/lsb-release file is not part of the lsb >>>> spec. A proposal to either define an API to this information, or to >>>> document the format of this file didn't find much enthusiasm on the LSB >>>> ML. So I would like to stay with the current approch, and read the file >>>> if available. >>>> >>>> Matthias >>> >>> >> > > From Dmitry.Samersoff at oracle.com Wed Apr 20 04:34:13 2011 From: Dmitry.Samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 20 Apr 2011 15:34:13 +0400 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <4DAEC236.2090706@oracle.com> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DADA957.8050004@ubuntu.com> <4DAEA8BC.2030801@oracle.com> <4DAEAC8C.8060901@ubuntu.com> <4DAEC236.2090706@oracle.com> Message-ID: <4DAEC4B5.4000109@oracle.com> Oops, press send too early ... sorry! Matthias, What is the purpose of this identification? When you install/upgrade distribution using a way official for this distribution you will end up running the kernel with proper version string. (e.g. (Ubuntu/Linaro 4.4.4-14ubuntu5) ) if we like to have not only ubuntu but ubuntu 10.3 you have to read /etc/*-releases but this file doesn't reflect partial upgrades of running system (e.g kernel or libc upgrade) so value of this number is doubtful for me. -Dmitry On 2011-04-20 15:23, Dmitry Samersoff wrote: > Matthias, > > What is the purpose of this identification? > > -Dmitry > > On 2011-04-20 13:51, Matthias Klose wrote: >> No, that would be completely wrong. /proc/version tells you something >> about the running kernel, not about the distribution. >> >> On 04/20/2011 11:34 AM, Dmitry Samersoff wrote: >>> Matthias, >>> >>> Can't we just read /proc/version ? >>> >>> e.g.: >>> >>> Linux version 2.6.25-14.fc9.x86_64 (mockbuild@) (gcc version 4.3.0 >>> 20080428 (Red >>> Hat 4.3.0-8) (GCC) ) #1 SMP Thu May 1 06:06:21 EDT 2008 >>> >>> Linux version 2.6.38.2 (root at yoda) (gcc version 4.3.4 (Gentoo 4.3.4 >>> p1.0, >>> pie-10.1.5) ) #1 SMP PREEMPT Sat Apr 16 00:19:00 MSD 20 >>> >>> >>> >>> On 2011-04-19 19:25, Matthias Klose wrote: >>>> plus the format for the /etc/lsb-release file is not part of the lsb >>>> spec. A proposal to either define an API to this information, or to >>>> document the format of this file didn't find much enthusiasm on the LSB >>>> ML. So I would like to stay with the current approch, and read the file >>>> if available. >>>> >>>> Matthias >>> >>> >> > > -- Dmitry Samersoff Java Hotspot development team, SPB04 * There will come soft rains ... From doko at ubuntu.com Wed Apr 20 04:44:10 2011 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 20 Apr 2011 13:44:10 +0200 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <4DAEC4B5.4000109@oracle.com> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DADA957.8050004@ubuntu.com> <4DAEA8BC.2030801@oracle.com> <4DAEAC8C.8060901@ubuntu.com> <4DAEC236.2090706@oracle.com> <4DAEC4B5.4000109@oracle.com> Message-ID: <4DAEC70A.9000406@ubuntu.com> On 04/20/2011 01:34 PM, Dmitry Samersoff wrote: > What is the purpose of this identification? > > When you install/upgrade distribution using a way official for this distribution > you will end up running the kernel with proper version string. (e.g. > (Ubuntu/Linaro 4.4.4-14ubuntu5) ) > > if we like to have not only ubuntu but ubuntu 10.3 you have to read > /etc/*-releases but this file doesn't reflect partial upgrades of running system > (e.g kernel or libc upgrade) so value of this number is doubtful for me. At least Ubuntu doesn't support partial upgrades. The version number in /etc/lsb-release is finally set for the release candidate of a release. Unless you see "development" in this file, you should trust the version number. Now, running another distribution in a chroot would report the wrong kernel version. I don't mind if you report this information too, but omitting the distro information seems a bit odd. Matthias From bugzilla-daemon at icedtea.classpath.org Wed Apr 20 05:25:24 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 20 Apr 2011 12:25:24 +0000 Subject: [Bug 696] New: Zero fails to handle fast_aldc and fast_aldc_w in hs20 Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=696 Summary: Zero fails to handle fast_aldc and fast_aldc_w in hs20 Product: IcedTea Version: 6-hg Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Zero AssignedTo: unassigned at icedtea.classpath.org ReportedBy: xerxes at zafena.se hs20 uses two new internal instructions fast_aldc and fast_aldc_w. see: openjdk/hotspot/src/share/vm/interpreter/bytecodes.hpp This are handled by Zero in hotspot_comp upstream. We need to backport the following: This part from 7032458: Zero and Shark fixes http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/e863062e521d --- a/src/share/vm/interpreter/bytecodeInterpreter.cpp Sun Apr 03 12:00:54 2011 +0200 +++ b/src/share/vm/interpreter/bytecodeInterpreter.cpp Mon Apr 04 03:02:00 2011 -0700 @@ -568,7 +568,7 @@ BytecodeInterpreter::run(interpreterStat /* 0xDC */ &&opc_default, &&opc_default, &&opc_default, &&opc_default, /* 0xE0 */ &&opc_default, &&opc_default, &&opc_default, &&opc_default, -/* 0xE4 */ &&opc_default, &&opc_return_register_finalizer, &&opc_default, &&opc_default, +/* 0xE4 */ &&opc_default, &&opc_default, &&opc_default, &&opc_return_register_finalizer, /* 0xE8 */ &&opc_default, &&opc_default, &&opc_default, &&opc_default, /* 0xEC */ &&opc_default, &&opc_default, &&opc_default, &&opc_default, And this changeset from 7030207: Zero tweak to remove accidentally incorporated code: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/151da0c145a8 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From asu at redhat.com Wed Apr 20 06:00:25 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 09:00:25 -0400 (EDT) Subject: [rfc][icedtea-web]: Tell lruHandler to store after modifying. In-Reply-To: <44555219.80778.1303304363432.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1601709386.80799.1303304425104.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hello, It seems like the previous email[1] did not reach some people's inboxes.. Resending as new thread. [1]http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013722.html Regards, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.patch Type: text/x-patch Size: 511 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/f61a4526/patch.patch From bugzilla-daemon at icedtea.classpath.org Wed Apr 20 06:01:47 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 20 Apr 2011 13:01:47 +0000 Subject: [Bug 696] Zero fails to handle fast_aldc and fast_aldc_w in hs20 In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=696 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|unassigned at icedtea.classpath|xerxes at zafena.se |.org | Status|NEW |ASSIGNED --- Comment #1 from Xerxes R?nby 2011-04-20 13:01:46 --- Created an attachment (id=519) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=519) icedtea6-pr696-zero-fast_aldc-hs20.patch -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dlila at redhat.com Wed Apr 20 06:19:22 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 20 Apr 2011 09:19:22 -0400 (EDT) Subject: [rfc][icedtea-web]: Tell lruHandler to store after modifying. In-Reply-To: <1601709386.80799.1303304425104.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <968309526.617876.1303305562634.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > It seems like the previous email[1] did not reach some people's > inboxes.. Resending as new thread. > > [1]http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013722.html Ok with me. Regards, Denis. ----- Original Message ----- > Hello, > > > Regards, > Andrew From asu at icedtea.classpath.org Wed Apr 20 06:25:13 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Wed, 20 Apr 2011 13:25:13 +0000 Subject: /hg/icedtea-web: Store lru after modifying the entries Message-ID: changeset bc48727cfc1a in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=bc48727cfc1a author: Andrew Su date: Wed Apr 20 09:26:50 2011 -0400 Store lru after modifying the entries diffstat: ChangeLog | 5 +++++ netx/net/sourceforge/jnlp/cache/CacheUtil.java | 1 + 2 files changed, 6 insertions(+), 0 deletions(-) diffs (23 lines): diff -r 211a5e73d119 -r bc48727cfc1a ChangeLog --- a/ChangeLog Mon Apr 18 17:38:31 2011 -0400 +++ b/ChangeLog Wed Apr 20 09:26:50 2011 -0400 @@ -1,3 +1,8 @@ +2011-04-20 Andrew Su + + * netx/net/sourceforge/jnlp/cache/CacheUtil.java: + (getCacheFile): Store lru after modifying. + 2011-04-18 Andrew Su * netx/net/sourceforge/jnlp/cache/CacheEntry.java: diff -r 211a5e73d119 -r bc48727cfc1a netx/net/sourceforge/jnlp/cache/CacheUtil.java --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 17:38:31 2011 -0400 +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 09:26:50 2011 -0400 @@ -307,6 +307,7 @@ if (cacheFile == null) { // We did not find a copy of it. cacheFile = makeNewCacheFile(source, version); } + lruHandler.store(); lruHandler.unlock(); } return cacheFile; From asu at redhat.com Wed Apr 20 06:48:24 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 09:48:24 -0400 (EDT) Subject: [RFC][IcedTea-Web]: Renable setting cache size limit on itw-settings In-Reply-To: <1019845058.82401.1303307007081.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <1214996483.82533.1303307304636.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> hello, This patch re-enables the controls in itw-settings to set a limit on cache items. Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: reenable_settings.patch Type: text/x-patch Size: 2687 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/11104076/reenable_settings.patch From dbhole at redhat.com Wed Apr 20 07:17:27 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 10:17:27 -0400 Subject: [RFC][IcedTea-Web]: Renable setting cache size limit on itw-settings In-Reply-To: <1214996483.82533.1303307304636.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1019845058.82401.1303307007081.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <1214996483.82533.1303307304636.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110420141727.GA15643@redhat.com> * Andrew Su [2011-04-20 09:49]: > hello, > > This patch re-enables the controls in itw-settings to set a limit on cache items. > Missing Changelog. It would be straightforward though. OK after adding changelog entry. Cheers, Deepak > Cheers, > Andrew > diff -r bc48727cfc1a netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java > --- a/netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java Wed Apr 20 09:26:50 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java Wed Apr 20 09:43:55 2011 -0400 > @@ -151,17 +151,15 @@ > } > }); > > - // TODO: This property is currently not honored, uncomment to enable when it is implemented. > - // This is to work with how much space is available for caching. > - // JLabel lCacheSize = new JLabel(Translator.R("TIFPCacheSize") + ":"); > - // slCacheSize = new JSlider(minSize, maxSize, Integer.parseInt(this.config.getProperty(properties[2]))); > - // slCacheSize.setMinorTickSpacing(50); > - // slCacheSize.setPaintTicks(true); > - // SpinnerNumberModel snmCacheSize = new SpinnerNumberModel(Integer.parseInt(this.config.getProperty(properties[2])), minSize, maxSize, 1); > - // spCacheSize = new JSpinner(snmCacheSize); > - // > - // slCacheSize.addChangeListener(this); > - // spCacheSize.addChangeListener(this); > + JLabel lCacheSize = new JLabel(Translator.R("TIFPCacheSize") + ":"); > + slCacheSize = new JSlider(minSize, maxSize, Integer.parseInt(this.config.getProperty(properties[2]))); > + slCacheSize.setMinorTickSpacing(50); > + slCacheSize.setPaintTicks(true); > + SpinnerNumberModel snmCacheSize = new SpinnerNumberModel(Integer.parseInt(this.config.getProperty(properties[2])), minSize, maxSize, 1); > + spCacheSize = new JSpinner(snmCacheSize); > + > + slCacheSize.addChangeListener(this); > + spCacheSize.addChangeListener(this); > > c.gridy = 0; > c.gridx = 0; > @@ -170,16 +168,16 @@ > c.gridx = 1; > c.weightx = 0; > diskSpacePanel.add(cbCompression, c); > - // c.gridy = 1; > - // c.gridx = 0; > - // c.gridwidth = GridBagConstraints.REMAINDER; > + c.gridy = 1; > + c.gridx = 0; > + c.gridwidth = GridBagConstraints.REMAINDER; > c.weightx = 1; > - // diskSpacePanel.add(lCacheSize, c); > - // c.gridwidth = 1; > - // c.gridy = 2; > - // diskSpacePanel.add(slCacheSize, c); > - // c.gridx = 1; > - // diskSpacePanel.add(spCacheSize, c); > + diskSpacePanel.add(lCacheSize, c); > + c.gridwidth = 1; > + c.gridy = 2; > + diskSpacePanel.add(slCacheSize, c); > + c.gridx = 1; > + diskSpacePanel.add(spCacheSize, c); > > JPanel buttonDeleteRestore = new JPanel(new FlowLayout(FlowLayout.TRAILING)); > JButton bViewFiles = new JButton(Translator.R("TIFPViewFiles")); From ahughes at redhat.com Wed Apr 20 07:22:58 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 15:22:58 +0100 Subject: IcedTea7 build failed for 2cd959df7e7a In-Reply-To: <1303282920.11416.11.camel@springer.wildebeest.org> References: <20110420015650.GM29985@rivendell.middle-earth.co.uk> <1303282920.11416.11.camel@springer.wildebeest.org> Message-ID: <20110420142258.GS29985@rivendell.middle-earth.co.uk> On 09:02 Wed 20 Apr , Mark Wielaard wrote: > On Wed, 2011-04-20 at 02:56 +0100, Dr Andrew John Hughes wrote: > > On 17:37 Mon 18 Apr , Mark Wielaard wrote: > > > The current IcedTea build fails. > > > > > snip... > > > > > Checking patches/cacao/launcher.patch > > > 1 out of 3 hunks FAILED -- saving rejects to file openjdk/jdk/src/share/bin/java.c.rej > > > ERROR patch patches/cacao/launcher.patch FAILED! > > > WARNING make clean-patch before retrying a fix > > > make: *** [stamps/patch.stamp] Error 2 > > > > I'm not seeing this. Is this because these buildbots enable CACAO? > > Yes it uses: > > (cd $ICEDTEA_DIR && ./autogen.sh \ > && cd $ICEDTEA_BUILD_DIR \ > && $ICEDTEA_DIR/configure \ > --enable-nss \ > --with-additional-vms=cacao,shark \ > && make VERBOSE=true) 2>&1 | tee $BUILD_LOG_FILE > See http://icedtea.classpath.org/hg/buildbot/file/tip/icedtea/build.sh > > Other builders also seem to fail currently. See e.g. > http://builder.classpath.org/icedtea/buildbot/builders/icedtea7-squeeze-x86_64-full/builds/10 > which has the full configure step in its logs (step 4). > > Cheers, > > Mark > Yes, well I haven't tested CACAO in a while. It's not high on my list of priorities. Getting the basic build working tends to be more important :-) -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From asu at redhat.com Wed Apr 20 07:25:15 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 10:25:15 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <20110419222901.GH15825@redhat.com> Message-ID: <1207815603.83522.1303309515393.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Deepak Bhole" > To: "Andrew Su" > Cc: "IcedTea" > Sent: Tuesday, April 19, 2011 6:29:01 PM > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > * Andrew Su [2011-04-19 17:30]: > > > > > > ----- Original Message ----- > > > + } catch (IOException e1) { > > + e1.printStackTrace(); > > > Why e1 and not e? e is being used for iterating through the entries already. I've attached an updated patch with some changes discussed on irc with Denis. > > Rest looks fine to me. Okay from me after above e1 -> e change. > > Cheers, > Deepak > > > + } > > + } > > + } > > } > > } else { > > lruHandler.removeEntry(key); > > @@ -560,20 +600,26 @@ > > } > > lruHandler.store(); > > > > - removeUntrackedDirectories(keep); > > + /* > > + * FIXME: if cacheDir is for example $USER_HOME and they have a > > folder called http > > + * and/or https. These would get removed. > > + */ > > + remove.add(cacheDir + File.separator + "http"); > > + remove.add(cacheDir + File.separator + "https"); > > + > > + remove.removeAll(keep); > > + > > + removeSetOfDirectories(remove); > > + > > } > > } > > > > - private static void removeUntrackedDirectories(Set keep) { > > - File temp = new File(cacheDir); > > - // Remove all folder not listed in keep. > > - for (File f : temp.listFiles()) { > > - if (f.isDirectory() && !keep.contains(f.getPath())) { > > - try { > > - FileUtils.recursiveDelete(f, f); > > - } catch (IOException e) { > > - e.printStackTrace(); > > - } > > + private static void removeSetOfDirectories(Set remove) { > > + for (String s : remove) { > > + File f = new File(s); > > + try { > > + FileUtils.recursiveDelete(f, f); > > + } catch (IOException e) { > > } > > } > > } -------------- next part -------------- A non-text attachment was scrubbed... Name: p.patch Type: text/x-patch Size: 5455 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/7f698bc4/p.patch From dbhole at redhat.com Wed Apr 20 07:26:04 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 10:26:04 -0400 Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <1207815603.83522.1303309515393.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <20110419222901.GH15825@redhat.com> <1207815603.83522.1303309515393.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110420142604.GC15643@redhat.com> * Andrew Su [2011-04-20 10:25]: > > > ----- Original Message ----- > > From: "Deepak Bhole" > > To: "Andrew Su" > > Cc: "IcedTea" > > Sent: Tuesday, April 19, 2011 6:29:01 PM > > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > > * Andrew Su [2011-04-19 17:30]: > > > > > > > > > ----- Original Message ----- > > > > > + } catch (IOException e1) { > > > + e1.printStackTrace(); > > > > > > Why e1 and not e? > > e is being used for iterating through the entries already. > > I've attached an updated patch with some changes discussed on irc with Denis. > What discussions? Please post this kind of stuff to the list.. Thanks, Deepak > > > > Rest looks fine to me. Okay from me after above e1 -> e change. > > > > Cheers, > > Deepak > > > > > + } > > > + } > > > + } > > > } > > > } else { > > > lruHandler.removeEntry(key); > > > @@ -560,20 +600,26 @@ > > > } > > > lruHandler.store(); > > > > > > - removeUntrackedDirectories(keep); > > > + /* > > > + * FIXME: if cacheDir is for example $USER_HOME and they have a > > > folder called http > > > + * and/or https. These would get removed. > > > + */ > > > + remove.add(cacheDir + File.separator + "http"); > > > + remove.add(cacheDir + File.separator + "https"); > > > + > > > + remove.removeAll(keep); > > > + > > > + removeSetOfDirectories(remove); > > > + > > > } > > > } > > > > > > - private static void removeUntrackedDirectories(Set keep) { > > > - File temp = new File(cacheDir); > > > - // Remove all folder not listed in keep. > > > - for (File f : temp.listFiles()) { > > > - if (f.isDirectory() && !keep.contains(f.getPath())) { > > > - try { > > > - FileUtils.recursiveDelete(f, f); > > > - } catch (IOException e) { > > > - e.printStackTrace(); > > > - } > > > + private static void removeSetOfDirectories(Set remove) { > > > + for (String s : remove) { > > > + File f = new File(s); > > > + try { > > > + FileUtils.recursiveDelete(f, f); > > > + } catch (IOException e) { > > > } > > > } > > > } > diff -r bc48727cfc1a netx/net/sourceforge/jnlp/cache/CacheUtil.java > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 09:26:50 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 10:24:52 2011 -0400 > @@ -533,7 +533,17 @@ > if (okToClearCache()) { > // First we want to figure out which stuff we need to delete. > HashSet keep = new HashSet(); > + HashSet remove = new HashSet(); > lruHandler.load(); > + > + long maxSize = -1; // Default > + try { > + maxSize = Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); > + } catch (NumberFormatException nfe) { > + } > + > + maxSize = maxSize << 20; // Convert from megabyte to byte (Negative values will be considered unlimited.) > + long curSize = 0; > > for (Entry e : lruHandler.getLRUSortedEntries()) { > // Check if the item is contained in cacheOrder. > @@ -541,18 +551,49 @@ > final String value = e.getValue(); > > if (value != null) { > + File file = new File(value); > PropertiesFile pf = new PropertiesFile(new File(value + ".info")); > boolean delete = Boolean.parseBoolean(pf.getProperty("delete")); > > - // This will get me the root directory specific to this cache item. > - String rStr = value.substring(cacheDir.length()); > + /* > + * This will get me the root directory specific to this cache item. > + * Example: > + * cacheDir = /home/user1/.icedtea/cache > + * file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar > + * rStr first becomes: /0/http/www.example.com/subdir/a.jar > + * then rstr becomes: /home/user1/.icedtea/cache/0 > + */ > + String rStr = file.getPath().substring(cacheDir.length()); > rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1)); > + long len = file.length(); > > - if (delete || keep.contains(rStr)) { > + /* > + * we remove entries from our lru if any of the following condition is met. > + * Conditions: > + * - delete: file has been marked for deletion. > + * - !file.isFile(): if someone tampered with the directory, file doesn't exist. > + * - maxSize >= 0 && curSize + len > maxSize: If a limit was set and the new size > + * on disk would exceed the maximum size. > + * - keep.contains(...): We had already decided to keep an entry with the same > + * url path. > + */ > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > maxSize) || > + keep.contains(file.getPath().substring(rStr.length()))) { > lruHandler.removeEntry(key); > + remove.add(rStr); > } else { > - keep.add(value.substring(rStr.length())); > - keep.add(rStr); // We can just use the same map, since these two things are disjoint with each other. > + curSize += len; > + keep.add(file.getPath().substring(rStr.length())); > + > + for (File f : file.getParentFile().listFiles()) { > + if (!(f.equals(file) || f.equals(pf.getStoreFile()))){ > + try { > + FileUtils.recursiveDelete(f, f); > + } catch (IOException e1) { > + e1.printStackTrace(); > + } > + } > + } > } > } else { > lruHandler.removeEntry(key); > @@ -560,20 +601,24 @@ > } > lruHandler.store(); > > - removeUntrackedDirectories(keep); > + /* > + * FIXME: if cacheDir is for example $USER_HOME and they have a folder called http > + * and/or https. These would get removed. > + */ > + remove.add(cacheDir + File.separator + "http"); > + remove.add(cacheDir + File.separator + "https"); > + > + removeSetOfDirectories(remove); > + > } > } > > - private static void removeUntrackedDirectories(Set keep) { > - File temp = new File(cacheDir); > - // Remove all folder not listed in keep. > - for (File f : temp.listFiles()) { > - if (f.isDirectory() && !keep.contains(f.getPath())) { > - try { > - FileUtils.recursiveDelete(f, f); > - } catch (IOException e) { > - e.printStackTrace(); > - } > + private static void removeSetOfDirectories(Set remove) { > + for (String s : remove) { > + File f = new File(s); > + try { > + FileUtils.recursiveDelete(f, f); > + } catch (IOException e) { > } > } > } From dlila at redhat.com Wed Apr 20 07:31:58 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 20 Apr 2011 10:31:58 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <20110420142604.GC15643@redhat.com> Message-ID: <404156815.627972.1303309918449.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > What discussions? Please post this kind of stuff to the list.. Right, sorry about that. Well, basically the sets remove and keep were disjoint, so remove.removeAll(keep) should be eliminated. Also, we were adding rStr to keep, but checking for file.getPath().substring(rStr.length()) which would always be false. With these changes, the patch looks good to me. Regards, Denis. ----- Original Message ----- > * Andrew Su [2011-04-20 10:25]: > > > > > > ----- Original Message ----- > > > From: "Deepak Bhole" > > > To: "Andrew Su" > > > Cc: "IcedTea" > > > Sent: Tuesday, April 19, 2011 6:29:01 PM > > > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > > > * Andrew Su [2011-04-19 17:30]: > > > > > > > > > > > > ----- Original Message ----- > > > > > > > + } catch (IOException e1) { > > > > + e1.printStackTrace(); > > > > > > > > > Why e1 and not e? > > > > e is being used for iterating through the entries already. > > > > I've attached an updated patch with some changes discussed on irc > > with Denis. > > > > > Thanks, > Deepak > > > > > > > Rest looks fine to me. Okay from me after above e1 -> e change. > > > > > > Cheers, > > > Deepak > > > > > > > + } > > > > + } > > > > + } > > > > } > > > > } else { > > > > lruHandler.removeEntry(key); > > > > @@ -560,20 +600,26 @@ > > > > } > > > > lruHandler.store(); > > > > > > > > - removeUntrackedDirectories(keep); > > > > + /* > > > > + * FIXME: if cacheDir is for example $USER_HOME and they have a > > > > folder called http > > > > + * and/or https. These would get removed. > > > > + */ > > > > + remove.add(cacheDir + File.separator + "http"); > > > > + remove.add(cacheDir + File.separator + "https"); > > > > + > > > > + remove.removeAll(keep); > > > > + > > > > + removeSetOfDirectories(remove); > > > > + > > > > } > > > > } > > > > > > > > - private static void removeUntrackedDirectories(Set > > > > keep) { > > > > - File temp = new File(cacheDir); > > > > - // Remove all folder not listed in keep. > > > > - for (File f : temp.listFiles()) { > > > > - if (f.isDirectory() && !keep.contains(f.getPath())) { > > > > - try { > > > > - FileUtils.recursiveDelete(f, f); > > > > - } catch (IOException e) { > > > > - e.printStackTrace(); > > > > - } > > > > + private static void removeSetOfDirectories(Set remove) > > > > { > > > > + for (String s : remove) { > > > > + File f = new File(s); > > > > + try { > > > > + FileUtils.recursiveDelete(f, f); > > > > + } catch (IOException e) { > > > > } > > > > } > > > > } > > > diff -r bc48727cfc1a netx/net/sourceforge/jnlp/cache/CacheUtil.java > > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 > > 09:26:50 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 > > 10:24:52 2011 -0400 > > @@ -533,7 +533,17 @@ > > if (okToClearCache()) { > > // First we want to figure out which stuff we need to > > delete. > > HashSet keep = new HashSet(); > > + HashSet remove = new HashSet(); > > lruHandler.load(); > > + > > + long maxSize = -1; // Default > > + try { > > + maxSize = > > Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); > > + } catch (NumberFormatException nfe) { > > + } > > + > > + maxSize = maxSize << 20; // Convert from megabyte to byte > > (Negative values will be considered unlimited.) > > + long curSize = 0; > > > > for (Entry e : > > lruHandler.getLRUSortedEntries()) { > > // Check if the item is contained in cacheOrder. > > @@ -541,18 +551,49 @@ > > final String value = e.getValue(); > > > > if (value != null) { > > + File file = new File(value); > > PropertiesFile pf = new PropertiesFile(new > > File(value + ".info")); > > boolean delete = > > Boolean.parseBoolean(pf.getProperty("delete")); > > > > - // This will get me the root directory specific to this cache > > item. > > - String rStr = value.substring(cacheDir.length()); > > + /* > > + * This will get me the root directory specific to this cache item. > > + * Example: > > + * cacheDir = /home/user1/.icedtea/cache > > + * file.getPath() = > > /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar > > + * rStr first becomes: /0/http/www.example.com/subdir/a.jar > > + * then rstr becomes: /home/user1/.icedtea/cache/0 > > + */ > > + String rStr = file.getPath().substring(cacheDir.length()); > > rStr = cacheDir + rStr.substring(0, > > rStr.indexOf(File.separatorChar, 1)); > > + long len = file.length(); > > > > - if (delete || keep.contains(rStr)) { > > + /* > > + * we remove entries from our lru if any of the following condition > > is met. > > + * Conditions: > > + * - delete: file has been marked for deletion. > > + * - !file.isFile(): if someone tampered with the directory, file > > doesn't exist. > > + * - maxSize >= 0 && curSize + len > maxSize: If a limit was set > > and the new size > > + * on disk would exceed the maximum size. > > + * - keep.contains(...): We had already decided to keep an entry > > with the same > > + * url path. > > + */ > > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > > > maxSize) || > > + keep.contains(file.getPath().substring(rStr.length()))) { > > lruHandler.removeEntry(key); > > + remove.add(rStr); > > } else { > > - keep.add(value.substring(rStr.length())); > > - keep.add(rStr); // We can just use the same map, since these two > > things are disjoint with each other. > > + curSize += len; > > + keep.add(file.getPath().substring(rStr.length())); > > + > > + for (File f : file.getParentFile().listFiles()) { > > + if (!(f.equals(file) || f.equals(pf.getStoreFile()))){ > > + try { > > + FileUtils.recursiveDelete(f, f); > > + } catch (IOException e1) { > > + e1.printStackTrace(); > > + } > > + } > > + } > > } > > } else { > > lruHandler.removeEntry(key); > > @@ -560,20 +601,24 @@ > > } > > lruHandler.store(); > > > > - removeUntrackedDirectories(keep); > > + /* > > + * FIXME: if cacheDir is for example $USER_HOME and they have a > > folder called http > > + * and/or https. These would get removed. > > + */ > > + remove.add(cacheDir + File.separator + "http"); > > + remove.add(cacheDir + File.separator + "https"); > > + > > + removeSetOfDirectories(remove); > > + > > } > > } > > > > - private static void removeUntrackedDirectories(Set keep) { > > - File temp = new File(cacheDir); > > - // Remove all folder not listed in keep. > > - for (File f : temp.listFiles()) { > > - if (f.isDirectory() && !keep.contains(f.getPath())) { > > - try { > > - FileUtils.recursiveDelete(f, f); > > - } catch (IOException e) { > > - e.printStackTrace(); > > - } > > + private static void removeSetOfDirectories(Set remove) { > > + for (String s : remove) { > > + File f = new File(s); > > + try { > > + FileUtils.recursiveDelete(f, f); > > + } catch (IOException e) { > > } > > } > > } From asu at redhat.com Wed Apr 20 07:34:04 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 10:34:04 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Don't allow itw-settings to remove cache items when plugin in use In-Reply-To: <1572144556.83797.1303309972700.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <130713432.83824.1303310044954.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hi, This patch is to make it so itw-settings won't remove cached items if plugin/javaws is in use. Perhaps a messagebox to inform the user of a running instance? Regards, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: do_not_del.patch Type: text/x-patch Size: 1917 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/2b749c16/do_not_del.patch From asu at icedtea.classpath.org Wed Apr 20 07:43:52 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Wed, 20 Apr 2011 14:43:52 +0000 Subject: /hg/icedtea-web: Unhide components for setting cache size limit ... Message-ID: changeset d17b410682ad in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=d17b410682ad author: Andrew Su date: Wed Apr 20 10:44:58 2011 -0400 Unhide components for setting cache size limit in itw-settings diffstat: ChangeLog | 6 + netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java | 38 ++++----- 2 files changed, 24 insertions(+), 20 deletions(-) diffs (69 lines): diff -r bc48727cfc1a -r d17b410682ad ChangeLog --- a/ChangeLog Wed Apr 20 09:26:50 2011 -0400 +++ b/ChangeLog Wed Apr 20 10:44:58 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-20 Andrew Su + + * netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java: + (addComponents): Uncommented lines of code to reintroduce components + to handle setting cache size limit. + 2011-04-20 Andrew Su * netx/net/sourceforge/jnlp/cache/CacheUtil.java: diff -r bc48727cfc1a -r d17b410682ad netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java --- a/netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java Wed Apr 20 09:26:50 2011 -0400 +++ b/netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java Wed Apr 20 10:44:58 2011 -0400 @@ -151,17 +151,15 @@ } }); - // TODO: This property is currently not honored, uncomment to enable when it is implemented. - // This is to work with how much space is available for caching. - // JLabel lCacheSize = new JLabel(Translator.R("TIFPCacheSize") + ":"); - // slCacheSize = new JSlider(minSize, maxSize, Integer.parseInt(this.config.getProperty(properties[2]))); - // slCacheSize.setMinorTickSpacing(50); - // slCacheSize.setPaintTicks(true); - // SpinnerNumberModel snmCacheSize = new SpinnerNumberModel(Integer.parseInt(this.config.getProperty(properties[2])), minSize, maxSize, 1); - // spCacheSize = new JSpinner(snmCacheSize); - // - // slCacheSize.addChangeListener(this); - // spCacheSize.addChangeListener(this); + JLabel lCacheSize = new JLabel(Translator.R("TIFPCacheSize") + ":"); + slCacheSize = new JSlider(minSize, maxSize, Integer.parseInt(this.config.getProperty(properties[2]))); + slCacheSize.setMinorTickSpacing(50); + slCacheSize.setPaintTicks(true); + SpinnerNumberModel snmCacheSize = new SpinnerNumberModel(Integer.parseInt(this.config.getProperty(properties[2])), minSize, maxSize, 1); + spCacheSize = new JSpinner(snmCacheSize); + + slCacheSize.addChangeListener(this); + spCacheSize.addChangeListener(this); c.gridy = 0; c.gridx = 0; @@ -170,16 +168,16 @@ c.gridx = 1; c.weightx = 0; diskSpacePanel.add(cbCompression, c); - // c.gridy = 1; - // c.gridx = 0; - // c.gridwidth = GridBagConstraints.REMAINDER; + c.gridy = 1; + c.gridx = 0; + c.gridwidth = GridBagConstraints.REMAINDER; c.weightx = 1; - // diskSpacePanel.add(lCacheSize, c); - // c.gridwidth = 1; - // c.gridy = 2; - // diskSpacePanel.add(slCacheSize, c); - // c.gridx = 1; - // diskSpacePanel.add(spCacheSize, c); + diskSpacePanel.add(lCacheSize, c); + c.gridwidth = 1; + c.gridy = 2; + diskSpacePanel.add(slCacheSize, c); + c.gridx = 1; + diskSpacePanel.add(spCacheSize, c); JPanel buttonDeleteRestore = new JPanel(new FlowLayout(FlowLayout.TRAILING)); JButton bViewFiles = new JButton(Translator.R("TIFPViewFiles")); From dbhole at redhat.com Wed Apr 20 08:39:01 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 11:39:01 -0400 Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <404156815.627972.1303309918449.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <20110420142604.GC15643@redhat.com> <404156815.627972.1303309918449.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110420153901.GA12304@redhat.com> * Denis Lila [2011-04-20 10:31]: > > What discussions? Please post this kind of stuff to the list.. > > Right, sorry about that. > > Well, basically the sets remove and keep were disjoint, so > remove.removeAll(keep) should be eliminated. > > Also, we were adding rStr to keep, but checking for > file.getPath().substring(rStr.length()) which > would always be false. > > With these changes, the patch looks good to me. > Likewise. OK from me too. Deepak > Regards, > Denis. > > ----- Original Message ----- > > * Andrew Su [2011-04-20 10:25]: > > > > > > > > > ----- Original Message ----- > > > > From: "Deepak Bhole" > > > > To: "Andrew Su" > > > > Cc: "IcedTea" > > > > Sent: Tuesday, April 19, 2011 6:29:01 PM > > > > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > > > > * Andrew Su [2011-04-19 17:30]: > > > > > > > > > > > > > > > ----- Original Message ----- > > > > > > > > > + } catch (IOException e1) { > > > > > + e1.printStackTrace(); > > > > > > > > > > > > Why e1 and not e? > > > > > > e is being used for iterating through the entries already. > > > > > > I've attached an updated patch with some changes discussed on irc > > > with Denis. > > > > > > > > > > Thanks, > > Deepak > > > > > > > > > > Rest looks fine to me. Okay from me after above e1 -> e change. > > > > > > > > Cheers, > > > > Deepak > > > > > > > > > + } > > > > > + } > > > > > + } > > > > > } > > > > > } else { > > > > > lruHandler.removeEntry(key); > > > > > @@ -560,20 +600,26 @@ > > > > > } > > > > > lruHandler.store(); > > > > > > > > > > - removeUntrackedDirectories(keep); > > > > > + /* > > > > > + * FIXME: if cacheDir is for example $USER_HOME and they have a > > > > > folder called http > > > > > + * and/or https. These would get removed. > > > > > + */ > > > > > + remove.add(cacheDir + File.separator + "http"); > > > > > + remove.add(cacheDir + File.separator + "https"); > > > > > + > > > > > + remove.removeAll(keep); > > > > > + > > > > > + removeSetOfDirectories(remove); > > > > > + > > > > > } > > > > > } > > > > > > > > > > - private static void removeUntrackedDirectories(Set > > > > > keep) { > > > > > - File temp = new File(cacheDir); > > > > > - // Remove all folder not listed in keep. > > > > > - for (File f : temp.listFiles()) { > > > > > - if (f.isDirectory() && !keep.contains(f.getPath())) { > > > > > - try { > > > > > - FileUtils.recursiveDelete(f, f); > > > > > - } catch (IOException e) { > > > > > - e.printStackTrace(); > > > > > - } > > > > > + private static void removeSetOfDirectories(Set remove) > > > > > { > > > > > + for (String s : remove) { > > > > > + File f = new File(s); > > > > > + try { > > > > > + FileUtils.recursiveDelete(f, f); > > > > > + } catch (IOException e) { > > > > > } > > > > > } > > > > > } > > > > > diff -r bc48727cfc1a netx/net/sourceforge/jnlp/cache/CacheUtil.java > > > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 > > > 09:26:50 2011 -0400 > > > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 > > > 10:24:52 2011 -0400 > > > @@ -533,7 +533,17 @@ > > > if (okToClearCache()) { > > > // First we want to figure out which stuff we need to > > > delete. > > > HashSet keep = new HashSet(); > > > + HashSet remove = new HashSet(); > > > lruHandler.load(); > > > + > > > + long maxSize = -1; // Default > > > + try { > > > + maxSize = > > > Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); > > > + } catch (NumberFormatException nfe) { > > > + } > > > + > > > + maxSize = maxSize << 20; // Convert from megabyte to byte > > > (Negative values will be considered unlimited.) > > > + long curSize = 0; > > > > > > for (Entry e : > > > lruHandler.getLRUSortedEntries()) { > > > // Check if the item is contained in cacheOrder. > > > @@ -541,18 +551,49 @@ > > > final String value = e.getValue(); > > > > > > if (value != null) { > > > + File file = new File(value); > > > PropertiesFile pf = new PropertiesFile(new > > > File(value + ".info")); > > > boolean delete = > > > Boolean.parseBoolean(pf.getProperty("delete")); > > > > > > - // This will get me the root directory specific to this cache > > > item. > > > - String rStr = value.substring(cacheDir.length()); > > > + /* > > > + * This will get me the root directory specific to this cache item. > > > + * Example: > > > + * cacheDir = /home/user1/.icedtea/cache > > > + * file.getPath() = > > > /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar > > > + * rStr first becomes: /0/http/www.example.com/subdir/a.jar > > > + * then rstr becomes: /home/user1/.icedtea/cache/0 > > > + */ > > > + String rStr = file.getPath().substring(cacheDir.length()); > > > rStr = cacheDir + rStr.substring(0, > > > rStr.indexOf(File.separatorChar, 1)); > > > + long len = file.length(); > > > > > > - if (delete || keep.contains(rStr)) { > > > + /* > > > + * we remove entries from our lru if any of the following condition > > > is met. > > > + * Conditions: > > > + * - delete: file has been marked for deletion. > > > + * - !file.isFile(): if someone tampered with the directory, file > > > doesn't exist. > > > + * - maxSize >= 0 && curSize + len > maxSize: If a limit was set > > > and the new size > > > + * on disk would exceed the maximum size. > > > + * - keep.contains(...): We had already decided to keep an entry > > > with the same > > > + * url path. > > > + */ > > > + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > > > > maxSize) || > > > + keep.contains(file.getPath().substring(rStr.length()))) { > > > lruHandler.removeEntry(key); > > > + remove.add(rStr); > > > } else { > > > - keep.add(value.substring(rStr.length())); > > > - keep.add(rStr); // We can just use the same map, since these two > > > things are disjoint with each other. > > > + curSize += len; > > > + keep.add(file.getPath().substring(rStr.length())); > > > + > > > + for (File f : file.getParentFile().listFiles()) { > > > + if (!(f.equals(file) || f.equals(pf.getStoreFile()))){ > > > + try { > > > + FileUtils.recursiveDelete(f, f); > > > + } catch (IOException e1) { > > > + e1.printStackTrace(); > > > + } > > > + } > > > + } > > > } > > > } else { > > > lruHandler.removeEntry(key); > > > @@ -560,20 +601,24 @@ > > > } > > > lruHandler.store(); > > > > > > - removeUntrackedDirectories(keep); > > > + /* > > > + * FIXME: if cacheDir is for example $USER_HOME and they have a > > > folder called http > > > + * and/or https. These would get removed. > > > + */ > > > + remove.add(cacheDir + File.separator + "http"); > > > + remove.add(cacheDir + File.separator + "https"); > > > + > > > + removeSetOfDirectories(remove); > > > + > > > } > > > } > > > > > > - private static void removeUntrackedDirectories(Set keep) { > > > - File temp = new File(cacheDir); > > > - // Remove all folder not listed in keep. > > > - for (File f : temp.listFiles()) { > > > - if (f.isDirectory() && !keep.contains(f.getPath())) { > > > - try { > > > - FileUtils.recursiveDelete(f, f); > > > - } catch (IOException e) { > > > - e.printStackTrace(); > > > - } > > > + private static void removeSetOfDirectories(Set remove) { > > > + for (String s : remove) { > > > + File f = new File(s); > > > + try { > > > + FileUtils.recursiveDelete(f, f); > > > + } catch (IOException e) { > > > } > > > } > > > } From asu at icedtea.classpath.org Wed Apr 20 08:48:59 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Wed, 20 Apr 2011 15:48:59 +0000 Subject: /hg/icedtea-web: Enforce cache size limit Message-ID: changeset 6e89f860a35a in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=6e89f860a35a author: Andrew Su date: Wed Apr 20 11:48:16 2011 -0400 Enforce cache size limit diffstat: ChangeLog | 10 +++ netx/net/sourceforge/jnlp/cache/CacheUtil.java | 77 ++++++++++++++++++++----- 2 files changed, 71 insertions(+), 16 deletions(-) diffs (129 lines): diff -r d17b410682ad -r 6e89f860a35a ChangeLog --- a/ChangeLog Wed Apr 20 10:44:58 2011 -0400 +++ b/ChangeLog Wed Apr 20 11:48:16 2011 -0400 @@ -1,3 +1,13 @@ +2011-04-20 Andrew Su + + * netx/net/sourceforge/jnlp/cache/CacheUtil.java: + (cleanCache): Added check for removing files that are over set max + limit. + (removeUntrackedDirectories): Removed method. Replaced by + removeSetOfDirectories. + (removeSetOfDirectories): New method. Removes a given set of + directories. + 2011-04-20 Andrew Su * netx/net/sourceforge/jnlp/controlpanel/TemporaryInternetFilesPanel.java: diff -r d17b410682ad -r 6e89f860a35a netx/net/sourceforge/jnlp/cache/CacheUtil.java --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 10:44:58 2011 -0400 +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Wed Apr 20 11:48:16 2011 -0400 @@ -533,7 +533,17 @@ if (okToClearCache()) { // First we want to figure out which stuff we need to delete. HashSet keep = new HashSet(); + HashSet remove = new HashSet(); lruHandler.load(); + + long maxSize = -1; // Default + try { + maxSize = Long.parseLong(JNLPRuntime.getConfiguration().getProperty("deployment.cache.max.size")); + } catch (NumberFormatException nfe) { + } + + maxSize = maxSize << 20; // Convert from megabyte to byte (Negative values will be considered unlimited.) + long curSize = 0; for (Entry e : lruHandler.getLRUSortedEntries()) { // Check if the item is contained in cacheOrder. @@ -541,18 +551,49 @@ final String value = e.getValue(); if (value != null) { + File file = new File(value); PropertiesFile pf = new PropertiesFile(new File(value + ".info")); boolean delete = Boolean.parseBoolean(pf.getProperty("delete")); - // This will get me the root directory specific to this cache item. - String rStr = value.substring(cacheDir.length()); + /* + * This will get me the root directory specific to this cache item. + * Example: + * cacheDir = /home/user1/.icedtea/cache + * file.getPath() = /home/user1/.icedtea/cache/0/http/www.example.com/subdir/a.jar + * rStr first becomes: /0/http/www.example.com/subdir/a.jar + * then rstr becomes: /home/user1/.icedtea/cache/0 + */ + String rStr = file.getPath().substring(cacheDir.length()); rStr = cacheDir + rStr.substring(0, rStr.indexOf(File.separatorChar, 1)); + long len = file.length(); - if (delete || keep.contains(rStr)) { + /* + * we remove entries from our lru if any of the following condition is met. + * Conditions: + * - delete: file has been marked for deletion. + * - !file.isFile(): if someone tampered with the directory, file doesn't exist. + * - maxSize >= 0 && curSize + len > maxSize: If a limit was set and the new size + * on disk would exceed the maximum size. + * - keep.contains(...): We had already decided to keep an entry with the same + * url path. + */ + if (delete || !file.isFile() || (maxSize >= 0 && curSize + len > maxSize) || + keep.contains(file.getPath().substring(rStr.length()))) { lruHandler.removeEntry(key); + remove.add(rStr); } else { - keep.add(value.substring(rStr.length())); - keep.add(rStr); // We can just use the same map, since these two things are disjoint with each other. + curSize += len; + keep.add(file.getPath().substring(rStr.length())); + + for (File f : file.getParentFile().listFiles()) { + if (!(f.equals(file) || f.equals(pf.getStoreFile()))){ + try { + FileUtils.recursiveDelete(f, f); + } catch (IOException e1) { + e1.printStackTrace(); + } + } + } } } else { lruHandler.removeEntry(key); @@ -560,20 +601,24 @@ } lruHandler.store(); - removeUntrackedDirectories(keep); + /* + * FIXME: if cacheDir is for example $USER_HOME and they have a folder called http + * and/or https. These would get removed. + */ + remove.add(cacheDir + File.separator + "http"); + remove.add(cacheDir + File.separator + "https"); + + removeSetOfDirectories(remove); + } } - private static void removeUntrackedDirectories(Set keep) { - File temp = new File(cacheDir); - // Remove all folder not listed in keep. - for (File f : temp.listFiles()) { - if (f.isDirectory() && !keep.contains(f.getPath())) { - try { - FileUtils.recursiveDelete(f, f); - } catch (IOException e) { - e.printStackTrace(); - } + private static void removeSetOfDirectories(Set remove) { + for (String s : remove) { + File f = new File(s); + try { + FileUtils.recursiveDelete(f, f); + } catch (IOException e) { } } } From asu at redhat.com Wed Apr 20 08:55:49 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 11:55:49 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Enforce cache size limit. In-Reply-To: <20110420153901.GA12304@redhat.com> Message-ID: <408683275.86501.1303314949285.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Deepak Bhole" > To: "Denis Lila" > Cc: "IcedTea" , "Andrew Su" > Sent: Wednesday, April 20, 2011 11:39:01 AM > Subject: Re: [RFC][Icedtea-Web]: Enforce cache size limit. > * Denis Lila [2011-04-20 10:31]: > > > What discussions? Please post this kind of stuff to the list.. > > > > Right, sorry about that. > > > > Well, basically the sets remove and keep were disjoint, so > > remove.removeAll(keep) should be eliminated. > > > > Also, we were adding rStr to keep, but checking for > > file.getPath().substring(rStr.length()) which > > would always be false. > > > > With these changes, the patch looks good to me. > > > > Likewise. OK from me too. > > Deepak -- snip -- Thanks for the reviews. Pushed. Cheers, Andrew From omajid at redhat.com Wed Apr 20 09:09:10 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 12:09:10 -0400 Subject: [icedtea-web] RFC: Do not show prompts on exceptions for the plugin Message-ID: <4DAF0526.20402@redhat.com> Hi, If the plugin fails to load because of exceptions, the exceptions should be indicated by the applet loading screen. Showing users error dialog for applets not working does not seem too nice. But since applet loading/splash screens are not implemented, the attached patch disables the error message and makes the exceptions log to stdout/stderr. ChangeLog: 2011-04-20 Omair Majid * plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java (PluginAppletSecurityContext): Set the launch handler to the stdout/stderr based one. Any thoughts or suggestions? Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-web-plugin-no-popup-exceptions.patch Type: text/x-patch Size: 823 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/143d795c/icedtea-web-plugin-no-popup-exceptions.patch From dbhole at redhat.com Wed Apr 20 10:09:13 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 13:09:13 -0400 Subject: [icedtea-web] RFC: Do not show prompts on exceptions for the plugin In-Reply-To: <4DAF0526.20402@redhat.com> References: <4DAF0526.20402@redhat.com> Message-ID: <20110420170912.GB12304@redhat.com> * Omair Majid [2011-04-20 12:10]: > Hi, > > If the plugin fails to load because of exceptions, the exceptions > should be indicated by the applet loading screen. Showing users > error dialog for applets not working does not seem too nice. But > since applet loading/splash screens are not implemented, the > attached patch disables the error message and makes the exceptions > log to stdout/stderr. > > ChangeLog: > 2011-04-20 Omair Majid > > * plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java > (PluginAppletSecurityContext): Set the launch handler to the > stdout/stderr based one. > > Any thoughts or suggestions? > Looks fine to me. OK for head. Cheers, Deepak > Cheers, > Omair > diff -r 211a5e73d119 plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java > --- a/plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java Mon Apr 18 17:38:31 2011 -0400 > +++ b/plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java Wed Apr 20 12:02:49 2011 -0400 > @@ -58,6 +58,7 @@ > import java.util.Map; > > import net.sourceforge.jnlp.runtime.JNLPRuntime; > +import net.sourceforge.jnlp.DefaultLaunchHandler; > import netscape.javascript.JSObjectCreatePermission; > > class Signature { > @@ -242,6 +243,7 @@ > // that JNLPRuntime will try to install > if (System.getSecurityManager() == null) { > JNLPRuntime.initialize(/* isApplication */false); > + JNLPRuntime.setDefaultLaunchHandler(new DefaultLaunchHandler()); > } > > JNLPRuntime.disableExit(); From dbhole at redhat.com Wed Apr 20 10:13:32 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 13:13:32 -0400 Subject: [RFC][Icedtea-Web]: Don't allow itw-settings to remove cache items when plugin in use In-Reply-To: <130713432.83824.1303310044954.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1572144556.83797.1303309972700.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <130713432.83824.1303310044954.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110420171332.GC12304@redhat.com> * Andrew Su [2011-04-20 10:35]: > Hi, > > This patch is to make it so itw-settings won't remove cached items if plugin/javaws is in use. > > Perhaps a messagebox to inform the user of a running instance? > Please post changelog entry. Also, if there is no lock file, the cache won't get cleared. We cannot assume that the lock file will always exist. Cheers, Deepak > Regards, > Andrew > diff -r bc48727cfc1a netx/net/sourceforge/jnlp/controlpanel/CachePane.java > --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 09:26:50 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 10:34:54 2011 -0400 > @@ -26,6 +26,9 @@ > import java.awt.GridLayout; > import java.awt.event.ActionEvent; > import java.awt.event.ActionListener; > +import java.io.FileNotFoundException; > +import java.io.IOException; > +import java.nio.channels.FileLock; > import java.text.SimpleDateFormat; > import java.util.ArrayList; > import java.util.List; > @@ -125,8 +128,17 @@ > deleteButton.addActionListener(new ActionListener() { > @Override > public void actionPerformed(ActionEvent e) { > + String netxRunningFile = config.getProperty(DeploymentConfiguration.KEY_USER_NETX_RUNNING_FILE); > + FileLock fl = null; > + try { > + fl = FileUtils.getFileLock(netxRunningFile, false, false); > + } catch (FileNotFoundException e1) { > + e1.printStackTrace(); > + } > + > int row = cacheTable.getSelectedRow(); > try { > + if (fl == null) return; > if (row == -1 || row > cacheTable.getRowCount() - 1) > return; > int modelRow = cacheTable.convertRowIndexToModel(row); > @@ -141,6 +153,15 @@ > } catch (Exception exception) { > //ignore > } > + > + if (fl != null) { > + try { > + fl.release(); > + fl.channel().close(); > + } catch (IOException e1) { > + e1.printStackTrace(); > + } > + } > } > }); > buttons.add(deleteButton); From omajid at redhat.com Wed Apr 20 10:18:49 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 13:18:49 -0400 Subject: [icedtea-web] RFC: PR687 In-Reply-To: <4DA8753B.6040606@redhat.com> References: <4DA8753B.6040606@redhat.com> Message-ID: <4DAF1579.1050305@redhat.com> On 04/15/2011 12:41 PM, Omair Majid wrote: > Hi, > > This is a (slightly updated) patch for PR687 [1]. > > The patch modifies how we try to find the JNLPClassLoader (from which we > find the ApplicationInstance). We first search the Context ClassLoader > (and it's parents) and then we search the ClassLoader for the classes on > the stack (and their parents). > > Any thoughts or comments? > > ChangeLog > 2011-04-15 Omair Majid > > * netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java > (getApplication): Pass the current thread as a parameter. > (getApplication): Add extra argument, Thread. Search the Thread's > context classloader and its parent and then search the > ClassLoaders, and the parents, of the classes on the stack. > (getJnlpClassLoader): New method. > (checkExit): Pass current thread as a parameter to getApplication. > > > [1] http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 Any thoughts? Deepak, I would appreciate it if you could take a look at it. We use getApplication() in a number of places and a wrong decision made by getApplication() could have an impact on security. Thanks, Omair From omajid at redhat.com Wed Apr 20 10:19:31 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 13:19:31 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <4DA871EB.2060907@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> Message-ID: <4DAF15A3.3000900@redhat.com> On 04/15/2011 12:27 PM, Omair Majid wrote: > Updated patch attached. > > On 04/14/2011 08:50 PM, Dr Andrew John Hughes wrote: >> On 19:09 Thu 14 Apr , Omair Majid wrote: >> >> snip... >> >>> > Each String in the Map is a classpath entry. The '+' is used to >>> join the >>> > jar's directory with the actual jar name. As an example, consider the >>> > applet linked in the original email. The applet's jars are located at >>> > /applet/jar/*. The 'Class-Path' entries contain just the names of the >>> > jar - like foo.jar, bar.jar. The page (and hence the codebase) is >>> > /applet/. If we just joined the name of the jar with the codebase, the >>> > result is /applet/foo.jar, which is not the right path. This bit of >>> code >>> > above joins the original jar's path to the Class-Path jars to create >>> > paths like /applet/jar/foo.jar and /applet/jar/bar.jar. >>> > >>> > On second thought, perhaps I should have documented this a little >>> more. >>> > I thought my comment: >>> > // we want to search for jars in the same subdir on the server >>> > // as this jar, so find out that subdirectory >>> > was sufficient, but it may not be. >>> > >> My main issue was that I wasn't familiar with this jar referencing >> syntax, but >> if you can make the documentation any clearer, that's always good. >> > > Do the comments in getClassPathsFromManifest help? > >>>>>> > >> > if (index != null) >>>>>> > >> > jarIndexes.add(index); >>>>>> > >> > } >>>>>> > >> > @@ -1007,8 +1033,32 @@ >>>>>> > >> > try { >>>>>> > >> > result = loadClassExt(name); >>>>>> > >> > } catch (ClassNotFoundException cnfe) { >>>>>> > >> > + // Not found in external loader either >>>>>> > >> > >>>>>> > >> > - // Not found in external loader either. As a last resort, >>>>>> look in any available indexes >>>>>> > >> > + // Look in 'Class-Path' as specified in the manifest file >>>>>> > >> > + try { >>>>>> > >> > + for (String classpath: classpathsInManfest) { >>>>>> > >> > + JARDesc desc; >>>>>> > >> > + try { >>>>>> > >> > + URL jarUrl = new URL(file.getCodeBase(), classpath); >>>>>> > >> > + desc = new JARDesc(jarUrl, null, null, false, true, >>>>>> false, true); >>>>>> > >> > + } catch (MalformedURLException mfe) { >>>>>> > >> > + throw new ClassNotFoundException(name); >>>>>> > >> > + } >>>>>> > >> > + try { >>>>>> > >> > + addNewJar(desc); >>>>>> > >> > + } catch (Exception e) { >>>>>> > >> > + throw new ClassNotFoundException(name); >>>>>> > >> > + } >>>>>> > >> > + } >>>>>> > >> > + >>>>>> > >> > + result = loadClassExt(name); >>>>>> > >> > + return result; >>>>>> > >> > + } catch (ClassNotFoundException cnfe1) { >>>>>> > >> > + // continue below >>>>>> > >> > + } >>>>>> > >> > + >>>>>> > >> > + // As a last resort, look in any available indexes >>>> > > Exceptions are getting eaten. The CNFE should use the thrown >>>> exceptions as the initCause. I'm especially >>>> > > worried about just catching Exception; can we not be more specific? >>>> > > >>> > >>> > I believe we want exceptions to be eaten here. This method, loadClass, >>> > can only throw ClassNotFoundExceptions. It has to search in a few >>> > locations and attempt a number of things before it realizes that a >>> class >>> > can not be found. So the cause that it may throw (and that user >>> code may >>> > see) is very likely to be meaningless anyway. >>> > >> I have no problem with them throwing CNFEs but the cause should be there. >> If it's meaningless, it can be ignored, but if it's not there, we may >> lose >> essential debugging information. >> > > Ok, so I have modified the code to throw CNFE with causes. However, the > code then catches (and logs) it. This allows the other methods of > finding the jar to continue and the user code never gets to see the > original CNFE. > >>> > As for catching Exception, you do have a point. I had left it the >>> way it >>> > was originally (see the code below). I know that it can throw >>> > IllegalArgumentException if the Resource is not being tracked (which >>> > should not happen here). I suppose I can remove the catch block >>> completely. >>> > >> Try it. >> > > Done. I havent seen any problems with the patch. However, I still think > this is one of few cases where we should catch any exception and > continue as if nothing has happened. > Ping. Any other thoughts? Cheers, Omair From asu at redhat.com Wed Apr 20 11:01:02 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 14:01:02 -0400 (EDT) Subject: [RFC][Icedtea-Web]: Don't allow itw-settings to remove cache items when plugin in use In-Reply-To: <20110420171332.GC12304@redhat.com> Message-ID: <986657301.90231.1303322462130.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Deepak Bhole" > To: "Andrew Su" > Cc: "IcedTea" > Sent: Wednesday, April 20, 2011 1:13:32 PM > Subject: Re: [RFC][Icedtea-Web]: Don't allow itw-settings to remove cache items when plugin in use > * Andrew Su [2011-04-20 10:35]: > > Hi, > > > > This patch is to make it so itw-settings won't remove cached items > > if plugin/javaws is in use. > > > > Perhaps a messagebox to inform the user of a running instance? > > > > Please post changelog entry. > > Also, if there is no lock file, the cache won't get cleared. We cannot > assume that the lock file will always exist. Ah yes, you are absolutely right. updated. ChangeLog: 2011-04-20 Andrew Su * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: (createButtonPanel): Added check to delete button for whether plugin or javaws is not running before proceeding with delete. --snip-- Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: patch1.patch Type: text/x-patch Size: 2248 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/272952e7/patch1.patch From omajid at redhat.com Wed Apr 20 11:19:34 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 14:19:34 -0400 Subject: IcedTea7 build failed for 2cd959df7e7a In-Reply-To: <20110420142258.GS29985@rivendell.middle-earth.co.uk> References: <20110420015650.GM29985@rivendell.middle-earth.co.uk> <1303282920.11416.11.camel@springer.wildebeest.org> <20110420142258.GS29985@rivendell.middle-earth.co.uk> Message-ID: <4DAF23B6.1010907@redhat.com> On 04/20/2011 10:22 AM, Dr Andrew John Hughes wrote: > On 09:02 Wed 20 Apr , Mark Wielaard wrote: >> On Wed, 2011-04-20 at 02:56 +0100, Dr Andrew John Hughes wrote: >>> On 17:37 Mon 18 Apr , Mark Wielaard wrote: >>>> The current IcedTea build fails. >>>> >>> snip... >>> >>>> Checking patches/cacao/launcher.patch >>>> 1 out of 3 hunks FAILED -- saving rejects to file openjdk/jdk/src/share/bin/java.c.rej >>>> ERROR patch patches/cacao/launcher.patch FAILED! >>>> WARNING make clean-patch before retrying a fix >>>> make: *** [stamps/patch.stamp] Error 2 >>> >>> I'm not seeing this. Is this because these buildbots enable CACAO? >> >> Yes it uses: >> >> (cd $ICEDTEA_DIR&& ./autogen.sh \ >> && cd $ICEDTEA_BUILD_DIR \ >> && $ICEDTEA_DIR/configure \ >> --enable-nss \ >> --with-additional-vms=cacao,shark \ >> && make VERBOSE=true) 2>&1 | tee $BUILD_LOG_FILE >> See http://icedtea.classpath.org/hg/buildbot/file/tip/icedtea/build.sh >> >> Other builders also seem to fail currently. See e.g. >> http://builder.classpath.org/icedtea/buildbot/builders/icedtea7-squeeze-x86_64-full/builds/10 >> which has the full configure step in its logs (step 4). >> >> Cheers, >> >> Mark >> > > Yes, well I haven't tested CACAO in a while. It's not high on my list of priorities. > Getting the basic build working tends to be more important :-) I dug into the cacao errors, and it turns out there are some real issues. The attached patch updates the cacao patches to apply, but it is not sufficient. Cacao relies on hpi which was removed in OpenJDK7. Some of the hpi methods are trivial (Close(int) becomes ::close(int)), but others (like NativePath(char*)) are non-trivial. I suppose I can copy over the implementation of those methods from hotspot, but I would prefer to avoid doing this as an icedtea patch. Perhaps upstream cacao should be taking care of this. Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea7-make-cacao-patches-apply.patch Type: text/x-patch Size: 1169 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/b0b8e90c/icedtea7-make-cacao-patches-apply.patch From dbhole at redhat.com Wed Apr 20 11:24:38 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 14:24:38 -0400 Subject: [icedtea-web] RFC: PR687 In-Reply-To: <4DA8753B.6040606@redhat.com> References: <4DA8753B.6040606@redhat.com> Message-ID: <20110420182437.GD12304@redhat.com> * Omair Majid [2011-04-15 12:42]: > Hi, > > This is a (slightly updated) patch for PR687 [1]. > > The patch modifies how we try to find the JNLPClassLoader (from > which we find the ApplicationInstance). We first search the Context > ClassLoader (and it's parents) and then we search the ClassLoader > for the classes on the stack (and their parents). > Patch looks okay to me. From a security perspective, the contextloader should be unique for jnlps and for applets it will only be same based on the cl sharing rules which is fine (within limits of the current design). Btw, what is the motivation for this? Was there a case where an incorrect loader was being returned off the stack? Cheers, Deepak From dbhole at redhat.com Wed Apr 20 11:26:57 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 14:26:57 -0400 Subject: [RFC][Icedtea-Web]: Don't allow itw-settings to remove cache items when plugin in use In-Reply-To: <986657301.90231.1303322462130.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <20110420171332.GC12304@redhat.com> <986657301.90231.1303322462130.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110420182656.GE12304@redhat.com> * Andrew Su [2011-04-20 14:01]: > > Ah yes, you are absolutely right. updated. > Looks fine now. Okay for head. Cheers, Deepak > ChangeLog: > 2011-04-20 Andrew Su > > * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: > (createButtonPanel): Added check to delete button for whether plugin > or javaws is not running before proceeding with delete. > > > --snip-- > > Cheers, > Andrew > diff -r 6e89f860a35a netx/net/sourceforge/jnlp/controlpanel/CachePane.java > --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 11:48:16 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 14:02:28 2011 -0400 > @@ -26,6 +26,10 @@ > import java.awt.GridLayout; > import java.awt.event.ActionEvent; > import java.awt.event.ActionListener; > +import java.io.File; > +import java.io.FileNotFoundException; > +import java.io.IOException; > +import java.nio.channels.FileLock; > import java.text.SimpleDateFormat; > import java.util.ArrayList; > import java.util.List; > @@ -125,8 +129,25 @@ > deleteButton.addActionListener(new ActionListener() { > @Override > public void actionPerformed(ActionEvent e) { > + FileLock fl = null; > + File netxRunningFile = new File(config.getProperty(DeploymentConfiguration.KEY_USER_NETX_RUNNING_FILE)); > + if (!netxRunningFile.exists()) { > + try { > + FileUtils.createParentDir(netxRunningFile); > + FileUtils.createRestrictedFile(netxRunningFile, true); > + } catch (IOException e1) { > + e1.printStackTrace(); > + } > + } > + > + try { > + fl = FileUtils.getFileLock(netxRunningFile.getPath(), false, false); > + } catch (FileNotFoundException e1) { > + } > + > int row = cacheTable.getSelectedRow(); > try { > + if (fl == null) return; > if (row == -1 || row > cacheTable.getRowCount() - 1) > return; > int modelRow = cacheTable.convertRowIndexToModel(row); > @@ -141,6 +162,15 @@ > } catch (Exception exception) { > //ignore > } > + > + if (fl != null) { > + try { > + fl.release(); > + fl.channel().close(); > + } catch (IOException e1) { > + e1.printStackTrace(); > + } > + } > } > }); > buttons.add(deleteButton); From asu at icedtea.classpath.org Wed Apr 20 11:33:48 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Wed, 20 Apr 2011 18:33:48 +0000 Subject: /hg/icedtea-web: Allow delete only when plugin or javaws is not ... Message-ID: changeset f0cccaba8060 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=f0cccaba8060 author: Andrew Su date: Wed Apr 20 14:35:13 2011 -0400 Allow delete only when plugin or javaws is not running diffstat: ChangeLog | 6 +++ netx/net/sourceforge/jnlp/controlpanel/CachePane.java | 30 +++++++++++++++++++ 2 files changed, 36 insertions(+), 0 deletions(-) diffs (69 lines): diff -r 6e89f860a35a -r f0cccaba8060 ChangeLog --- a/ChangeLog Wed Apr 20 11:48:16 2011 -0400 +++ b/ChangeLog Wed Apr 20 14:35:13 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-20 Andrew Su + + * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: + (createButtonPanel): Added check to delete button for whether plugin + or javaws is not running before proceeding with delete. + 2011-04-20 Andrew Su * netx/net/sourceforge/jnlp/cache/CacheUtil.java: diff -r 6e89f860a35a -r f0cccaba8060 netx/net/sourceforge/jnlp/controlpanel/CachePane.java --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 11:48:16 2011 -0400 +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 14:35:13 2011 -0400 @@ -26,6 +26,10 @@ import java.awt.GridLayout; import java.awt.event.ActionEvent; import java.awt.event.ActionListener; +import java.io.File; +import java.io.FileNotFoundException; +import java.io.IOException; +import java.nio.channels.FileLock; import java.text.SimpleDateFormat; import java.util.ArrayList; import java.util.List; @@ -125,8 +129,25 @@ deleteButton.addActionListener(new ActionListener() { @Override public void actionPerformed(ActionEvent e) { + FileLock fl = null; + File netxRunningFile = new File(config.getProperty(DeploymentConfiguration.KEY_USER_NETX_RUNNING_FILE)); + if (!netxRunningFile.exists()) { + try { + FileUtils.createParentDir(netxRunningFile); + FileUtils.createRestrictedFile(netxRunningFile, true); + } catch (IOException e1) { + e1.printStackTrace(); + } + } + + try { + fl = FileUtils.getFileLock(netxRunningFile.getPath(), false, false); + } catch (FileNotFoundException e1) { + } + int row = cacheTable.getSelectedRow(); try { + if (fl == null) return; if (row == -1 || row > cacheTable.getRowCount() - 1) return; int modelRow = cacheTable.convertRowIndexToModel(row); @@ -141,6 +162,15 @@ } catch (Exception exception) { //ignore } + + if (fl != null) { + try { + fl.release(); + fl.channel().close(); + } catch (IOException e1) { + e1.printStackTrace(); + } + } } }); buttons.add(deleteButton); From omajid at redhat.com Wed Apr 20 11:35:58 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 14:35:58 -0400 Subject: [icedtea-web] RFC: PR687 In-Reply-To: <20110420182437.GD12304@redhat.com> References: <4DA8753B.6040606@redhat.com> <20110420182437.GD12304@redhat.com> Message-ID: <4DAF278E.6050305@redhat.com> On 04/20/2011 02:24 PM, Deepak Bhole wrote: > * Omair Majid [2011-04-15 12:42]: >> Hi, >> >> This is a (slightly updated) patch for PR687 [1]. >> >> The patch modifies how we try to find the JNLPClassLoader (from >> which we find the ApplicationInstance). We first search the Context >> ClassLoader (and it's parents) and then we search the ClassLoader >> for the classes on the stack (and their parents). >> > > Patch looks okay to me. From a security perspective, the contextloader > should be unique for jnlps and for applets it will only be same based on > the cl sharing rules which is fine (within limits of the current design). > > Btw, what is the motivation for this? Was there a case where an > incorrect loader was being returned off the stack? > In general, the implementation was incomplete - it did not take account of applications which used their own ClassLoader to load classes. Please see http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 for more details and a reproducer. Cheers, Omair From dbhole at redhat.com Wed Apr 20 11:45:27 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 14:45:27 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <4DA871EB.2060907@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> Message-ID: <20110420184527.GF12304@redhat.com> * Omair Majid [2011-04-15 12:28]: > Updated patch attached. > I'll let Andrew reply to his concerns. I have only one concern (below): > - > - try { > - u = tracker.getCacheURL(remoteURL); > + addNewJar(desc); > } catch (Exception e) { > throw new ClassNotFoundException(name); > } > - We are catching any exception and re-throwing a CNFE. However exceptions could occur due to something like a file mentioned in the jarindex not existing on the server. This may not necessarily be fatal to the app (the class may exist in the next jar specified in the index). The CNFE will however make it fatal.. Cheers, Deepak From dbhole at redhat.com Wed Apr 20 11:47:40 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 14:47:40 -0400 Subject: [icedtea-web] RFC: PR687 In-Reply-To: <4DAF278E.6050305@redhat.com> References: <4DA8753B.6040606@redhat.com> <20110420182437.GD12304@redhat.com> <4DAF278E.6050305@redhat.com> Message-ID: <20110420184739.GG12304@redhat.com> * Omair Majid [2011-04-20 14:35]: > On 04/20/2011 02:24 PM, Deepak Bhole wrote: > >* Omair Majid [2011-04-15 12:42]: > >>Hi, > >> > >>This is a (slightly updated) patch for PR687 [1]. > >> > >>The patch modifies how we try to find the JNLPClassLoader (from > >>which we find the ApplicationInstance). We first search the Context > >>ClassLoader (and it's parents) and then we search the ClassLoader > >>for the classes on the stack (and their parents). > >> > > > >Patch looks okay to me. From a security perspective, the contextloader > >should be unique for jnlps and for applets it will only be same based on > >the cl sharing rules which is fine (within limits of the current design). > > > >Btw, what is the motivation for this? Was there a case where an > >incorrect loader was being returned off the stack? > > > > In general, the implementation was incomplete - it did not take > account of applications which used their own ClassLoader to load > classes. Please see > http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 for more > details and a reproducer. > Ah ok. Yeah thats what I figured too (an app creating its own loader and spawning a new thread causing the stack being filled with those classes). I did check out 687, couldn't find the source though, just .class files. Anyway, OK for head. Cheers, Deepak From asu at redhat.com Wed Apr 20 11:53:22 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 14:53:22 -0400 (EDT) Subject: [rfc][icedtea-web]: Update cache viewer to display information properly In-Reply-To: <1322317674.91202.1303325214863.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <63277565.91300.1303325602149.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hi, With the recent change to the cache directory, this patch will make itw-setting's cache viewer display the cache information properly. ChangeLog: 2011-04-20 Andrew Su * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: (generateData): Skip through the identifier for cached item. Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: patch0.patch Type: text/x-patch Size: 1710 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/585a5205/patch0.patch From dbhole at redhat.com Wed Apr 20 11:58:39 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 14:58:39 -0400 Subject: [rfc][icedtea-web]: Update cache viewer to display information properly In-Reply-To: <63277565.91300.1303325602149.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <1322317674.91202.1303325214863.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <63277565.91300.1303325602149.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110420185839.GI12304@redhat.com> * Andrew Su [2011-04-20 14:54]: > Hi, > > With the recent change to the cache directory, this patch will make itw-setting's cache viewer display the cache information properly. > > ChangeLog: > 2011-04-20 Andrew Su > > * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: > (generateData): Skip through the identifier for cached item. > Looks fairly straightforward. OK for head. Cheers, Deepak > Cheers, > Andrew > diff -r f0cccaba8060 netx/net/sourceforge/jnlp/controlpanel/CachePane.java > --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 14:35:13 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 14:42:57 2011 -0400 > @@ -235,16 +235,18 @@ > CacheDirectory.getDirStructure(root); > ArrayList data = new ArrayList(); > > - for (DirectoryNode type : root.getChildren()) { > - for (DirectoryNode domain : type.getChildren()) { > - for (DirectoryNode leaf : CacheDirectory.getLeafData(domain)) { > - Object[] o = { leaf, > - leaf.getFile().getAbsolutePath(), > - type, > - domain, > - leaf.getFile().length(), > - new SimpleDateFormat("MM/dd/yyyy").format(leaf.getFile().lastModified()) }; > - data.add(o); > + for (DirectoryNode identifier : root.getChildren()) { > + for (DirectoryNode type : identifier.getChildren()) { > + for (DirectoryNode domain : type.getChildren()) { > + for (DirectoryNode leaf : CacheDirectory.getLeafData(domain)) { > + Object[] o = { leaf, > + leaf.getFile().getAbsolutePath(), > + type, > + domain, > + leaf.getFile().length(), > + new SimpleDateFormat("MM/dd/yyyy").format(leaf.getFile().lastModified()) }; > + data.add(o); > + } > } > } > } From omajid at icedtea.classpath.org Wed Apr 20 11:59:16 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Wed, 20 Apr 2011 18:59:16 +0000 Subject: /hg/icedtea: Fix typo in stamp file name Message-ID: changeset a4851a2bf343 in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=a4851a2bf343 author: Omair Majid date: Wed Apr 20 14:58:03 2011 -0400 Fix typo in stamp file name diffstat: ChangeLog | 4 ++++ Makefile.am | 2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diffs (23 lines): diff -r bb4033154745 -r a4851a2bf343 ChangeLog --- a/ChangeLog Tue Apr 19 16:38:18 2011 -0400 +++ b/ChangeLog Wed Apr 20 14:58:03 2011 -0400 @@ -1,3 +1,7 @@ +2011-04-20 Omair Majid + + * Makefile.am (stamps/remove-intree-libraries.stamp): Typo in file name. + 2011-04-19 Omair Majid * patches/boot/test_gamma.patch: Skip test_gamma for shark too. diff -r bb4033154745 -r a4851a2bf343 Makefile.am --- a/Makefile.am Tue Apr 19 16:38:18 2011 -0400 +++ b/Makefile.am Wed Apr 20 14:58:03 2011 -0400 @@ -1240,7 +1240,7 @@ stamps/remove-intree-libraries.stamp: stamps/extract-openjdk.stamp sh $(srcdir)/remove-intree-libraries.sh - touch stamps/remove-intree-librares.stamp + touch stamps/remove-intree-libraries.stamp clean-remove-intree-libraries: rm -f stamps/remove-intree-libraries.stamp From asu at icedtea.classpath.org Wed Apr 20 12:01:23 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Wed, 20 Apr 2011 19:01:23 +0000 Subject: /hg/icedtea-web: Update itw-setting's cache viewer to display ne... Message-ID: changeset ad820e40fe56 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=ad820e40fe56 author: Andrew Su date: Wed Apr 20 15:02:56 2011 -0400 Update itw-setting's cache viewer to display new directory structure diffstat: ChangeLog | 5 ++++ netx/net/sourceforge/jnlp/controlpanel/CachePane.java | 22 ++++++++++-------- 2 files changed, 17 insertions(+), 10 deletions(-) diffs (44 lines): diff -r f0cccaba8060 -r ad820e40fe56 ChangeLog --- a/ChangeLog Wed Apr 20 14:35:13 2011 -0400 +++ b/ChangeLog Wed Apr 20 15:02:56 2011 -0400 @@ -1,3 +1,8 @@ +2011-04-20 Andrew Su + + * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: + (generateData): Skip through the identifier for cached item. + 2011-04-20 Andrew Su * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: diff -r f0cccaba8060 -r ad820e40fe56 netx/net/sourceforge/jnlp/controlpanel/CachePane.java --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 14:35:13 2011 -0400 +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 15:02:56 2011 -0400 @@ -235,16 +235,18 @@ CacheDirectory.getDirStructure(root); ArrayList data = new ArrayList(); - for (DirectoryNode type : root.getChildren()) { - for (DirectoryNode domain : type.getChildren()) { - for (DirectoryNode leaf : CacheDirectory.getLeafData(domain)) { - Object[] o = { leaf, - leaf.getFile().getAbsolutePath(), - type, - domain, - leaf.getFile().length(), - new SimpleDateFormat("MM/dd/yyyy").format(leaf.getFile().lastModified()) }; - data.add(o); + for (DirectoryNode identifier : root.getChildren()) { + for (DirectoryNode type : identifier.getChildren()) { + for (DirectoryNode domain : type.getChildren()) { + for (DirectoryNode leaf : CacheDirectory.getLeafData(domain)) { + Object[] o = { leaf, + leaf.getFile().getAbsolutePath(), + type, + domain, + leaf.getFile().length(), + new SimpleDateFormat("MM/dd/yyyy").format(leaf.getFile().lastModified()) }; + data.add(o); + } } } } From omajid at redhat.com Wed Apr 20 12:09:41 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 15:09:41 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <20110420184527.GF12304@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> Message-ID: <4DAF2F75.9010908@redhat.com> On 04/20/2011 02:45 PM, Deepak Bhole wrote: > * Omair Majid [2011-04-15 12:28]: >> Updated patch attached. >> > > I'll let Andrew reply to his concerns. I have only one concern (below): > >> - >> - try { >> - u = tracker.getCacheURL(remoteURL); >> + addNewJar(desc); >> } catch (Exception e) { >> throw new ClassNotFoundException(name); >> } >> - > > We are catching any exception and re-throwing a CNFE. However exceptions > could occur due to something like a file mentioned in the jarindex not > existing on the server. This may not necessarily be fatal to the app > (the class may exist in the next jar specified in the index). The CNFE > will however make it fatal.. > That's what I thought when I was going over this code - but that's how the old code was written. You can see that the new section that handles classpaths does not throw CNFE - it just logs the exception and continues. FWIW, addNewJar() and getCacheURL() do not throw any checked exceptions. I believe this is more of a safety net than anything else. Do you want me to update this code to just log the exception? On a slightly different note, this code needs to be moved to the findResource(s) methods. As it is, searching for anything other than classes will not use Class-Path jars or the JarIndexes. Thanks, Omair From dbhole at redhat.com Wed Apr 20 12:15:22 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 15:15:22 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <4DAF2F75.9010908@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> <4DAF2F75.9010908@redhat.com> Message-ID: <20110420191522.GK12304@redhat.com> * Omair Majid [2011-04-20 15:09]: > On 04/20/2011 02:45 PM, Deepak Bhole wrote: > >* Omair Majid [2011-04-15 12:28]: > >>Updated patch attached. > >> > > > >I'll let Andrew reply to his concerns. I have only one concern (below): > > > >>- > >>- try { > >>- u = tracker.getCacheURL(remoteURL); > >>+ addNewJar(desc); > >> } catch (Exception e) { > >> throw new ClassNotFoundException(name); > >> } > >>- > > > >We are catching any exception and re-throwing a CNFE. However exceptions > >could occur due to something like a file mentioned in the jarindex not > >existing on the server. This may not necessarily be fatal to the app > >(the class may exist in the next jar specified in the index). The CNFE > >will however make it fatal.. > > > > That's what I thought when I was going over this code - but that's > how the old code was written. You can see that the new section that > handles classpaths does not throw CNFE - it just logs the exception > and continues. > > FWIW, addNewJar() and getCacheURL() do not throw any checked > exceptions. I believe this is more of a safety net than anything > else. Do you want me to update this code to just log the exception? > Yes, I think that will be better. If the current code is throwing exceptions in such instances, it is incorrect IMO. > On a slightly different note, this code needs to be moved to the > findResource(s) methods. As it is, searching for anything other than > classes will not use Class-Path jars or the JarIndexes. > Good point. Would you be doing that? If so, do you want to do it in this patch or a new one? Cheers, Deepak From omajid at redhat.com Wed Apr 20 12:18:37 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 15:18:37 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <20110420191522.GK12304@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> <4DAF2F75.9010908@redhat.com> <20110420191522.GK12304@redhat.com> Message-ID: <4DAF318D.6030302@redhat.com> On 04/20/2011 03:15 PM, Deepak Bhole wrote: > * Omair Majid [2011-04-20 15:09]: >> On 04/20/2011 02:45 PM, Deepak Bhole wrote: >>> * Omair Majid [2011-04-15 12:28]: >>>> Updated patch attached. >>>> >>> >>> I'll let Andrew reply to his concerns. I have only one concern (below): >>> >>>> - >>>> - try { >>>> - u = tracker.getCacheURL(remoteURL); >>>> + addNewJar(desc); >>>> } catch (Exception e) { >>>> throw new ClassNotFoundException(name); >>>> } >>>> - >>> >>> We are catching any exception and re-throwing a CNFE. However exceptions >>> could occur due to something like a file mentioned in the jarindex not >>> existing on the server. This may not necessarily be fatal to the app >>> (the class may exist in the next jar specified in the index). The CNFE >>> will however make it fatal.. >>> >> >> That's what I thought when I was going over this code - but that's >> how the old code was written. You can see that the new section that >> handles classpaths does not throw CNFE - it just logs the exception >> and continues. >> >> FWIW, addNewJar() and getCacheURL() do not throw any checked >> exceptions. I believe this is more of a safety net than anything >> else. Do you want me to update this code to just log the exception? >> > > Yes, I think that will be better. If the current code is throwing > exceptions in such instances, it is incorrect IMO. > Sure, I will post an updated patch in a bit. >> On a slightly different note, this code needs to be moved to the >> findResource(s) methods. As it is, searching for anything other than >> classes will not use Class-Path jars or the JarIndexes. >> > > Good point. Would you be doing that? If so, do you want to do it in this > patch or a new one? > I can take care of it, but I would like to do it in a separate patch. I dont think this is important enough to block 1.1 branching. Cheers, Omair From dbhole at redhat.com Wed Apr 20 12:20:55 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 15:20:55 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <4DAF318D.6030302@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> <4DAF2F75.9010908@redhat.com> <20110420191522.GK12304@redhat.com> <4DAF318D.6030302@redhat.com> Message-ID: <20110420192054.GL12304@redhat.com> * Omair Majid [2011-04-20 15:18]: > On 04/20/2011 03:15 PM, Deepak Bhole wrote: > >* Omair Majid [2011-04-20 15:09]: > >>On 04/20/2011 02:45 PM, Deepak Bhole wrote: > >>>* Omair Majid [2011-04-15 12:28]: > >>>>Updated patch attached. > >>>> > >>> > >>>I'll let Andrew reply to his concerns. I have only one concern (below): > >>> > >>>>- > >>>>- try { > >>>>- u = tracker.getCacheURL(remoteURL); > >>>>+ addNewJar(desc); > >>>> } catch (Exception e) { > >>>> throw new ClassNotFoundException(name); > >>>> } > >>>>- > >>> > >>>We are catching any exception and re-throwing a CNFE. However exceptions > >>>could occur due to something like a file mentioned in the jarindex not > >>>existing on the server. This may not necessarily be fatal to the app > >>>(the class may exist in the next jar specified in the index). The CNFE > >>>will however make it fatal.. > >>> > >> > >>That's what I thought when I was going over this code - but that's > >>how the old code was written. You can see that the new section that > >>handles classpaths does not throw CNFE - it just logs the exception > >>and continues. > >> > >>FWIW, addNewJar() and getCacheURL() do not throw any checked > >>exceptions. I believe this is more of a safety net than anything > >>else. Do you want me to update this code to just log the exception? > >> > > > >Yes, I think that will be better. If the current code is throwing > >exceptions in such instances, it is incorrect IMO. > > > > Sure, I will post an updated patch in a bit. > > >>On a slightly different note, this code needs to be moved to the > >>findResource(s) methods. As it is, searching for anything other than > >>classes will not use Class-Path jars or the JarIndexes. > >> > > > >Good point. Would you be doing that? If so, do you want to do it in this > >patch or a new one? > > > > I can take care of it, but I would like to do it in a separate > patch. I dont think this is important enough to block 1.1 branching. > Fair enough. Please post an updated patch with just the exception change then and I will approve it. Thanks, Deepak > Cheers, > Omair From omajid at icedtea.classpath.org Wed Apr 20 12:24:24 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Wed, 20 Apr 2011 19:24:24 +0000 Subject: /hg/icedtea-web: Dont show error dialogs on exceptions with the ... Message-ID: changeset a3cbdab9bd7a in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=a3cbdab9bd7a author: Omair Majid date: Wed Apr 20 15:23:49 2011 -0400 Dont show error dialogs on exceptions with the plugin diffstat: ChangeLog | 6 ++++++ plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java | 2 ++ 2 files changed, 8 insertions(+), 0 deletions(-) diffs (32 lines): diff -r ad820e40fe56 -r a3cbdab9bd7a ChangeLog --- a/ChangeLog Wed Apr 20 15:02:56 2011 -0400 +++ b/ChangeLog Wed Apr 20 15:23:49 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-20 Omair Majid + + * plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java + (PluginAppletSecurityContext): Set the launch handler to the stdout/stderr + based one. + 2011-04-20 Andrew Su * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: diff -r ad820e40fe56 -r a3cbdab9bd7a plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java Wed Apr 20 15:02:56 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java Wed Apr 20 15:23:49 2011 -0400 @@ -58,6 +58,7 @@ import java.util.Map; import net.sourceforge.jnlp.runtime.JNLPRuntime; +import net.sourceforge.jnlp.DefaultLaunchHandler; import netscape.javascript.JSObjectCreatePermission; class Signature { @@ -242,6 +243,7 @@ // that JNLPRuntime will try to install if (System.getSecurityManager() == null) { JNLPRuntime.initialize(/* isApplication */false); + JNLPRuntime.setDefaultLaunchHandler(new DefaultLaunchHandler()); } JNLPRuntime.disableExit(); From omajid at redhat.com Wed Apr 20 12:24:52 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 15:24:52 -0400 Subject: [icedtea-web] RFC: Do not show prompts on exceptions for the plugin In-Reply-To: <20110420170912.GB12304@redhat.com> References: <4DAF0526.20402@redhat.com> <20110420170912.GB12304@redhat.com> Message-ID: <4DAF3304.7070608@redhat.com> On 04/20/2011 01:09 PM, Deepak Bhole wrote: > * Omair Majid [2011-04-20 12:10]: >> Hi, >> >> If the plugin fails to load because of exceptions, the exceptions >> should be indicated by the applet loading screen. Showing users >> error dialog for applets not working does not seem too nice. But >> since applet loading/splash screens are not implemented, the >> attached patch disables the error message and makes the exceptions >> log to stdout/stderr. >> >> ChangeLog: >> 2011-04-20 Omair Majid >> >> * plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java >> (PluginAppletSecurityContext): Set the launch handler to the >> stdout/stderr based one. >> >> Any thoughts or suggestions? >> > > Looks fine to me. OK for head. > Thanks for the review. I have pushed the changes to HEAD. Thanks, Omair From omajid at icedtea.classpath.org Wed Apr 20 12:34:37 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Wed, 20 Apr 2011 19:34:37 +0000 Subject: /hg/icedtea-web: PR687: BasicService.getCodeBase() returns null ... Message-ID: changeset 6528c988d538 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=6528c988d538 author: Omair Majid date: Wed Apr 20 15:34:10 2011 -0400 PR687: BasicService.getCodeBase() returns null for IcedTea6 1.9.7 + OSGI The patch modifies how we try to find the JNLPClassLoader (from which we find the ApplicationInstance). We first search the Context ClassLoader (and it's parents) and then we search the ClassLoader for the classes on the stack (and their parents). The Launcher always sets the Context ClassLoader of the applications/applets it launches. diffstat: ChangeLog | 9 ++ netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java | 56 ++++++++++---- 2 files changed, 49 insertions(+), 16 deletions(-) diffs (103 lines): diff -r a3cbdab9bd7a -r 6528c988d538 ChangeLog --- a/ChangeLog Wed Apr 20 15:23:49 2011 -0400 +++ b/ChangeLog Wed Apr 20 15:34:10 2011 -0400 @@ -1,3 +1,12 @@ +2011-04-20 Omair Majid + + * netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java + (getApplication(Class[],int)): Renamed to ... + (getApplication(Thread,Class[],int)): New method. Check the thread's + context ClassLoader as well as parents of the classloader. + (getJnlpClassLoader): New method. + (getApplication, checkExit): Update to work with new method signatures. + 2011-04-20 Omair Majid * plugin/icedteanp/java/sun/applet/PluginAppletSecurityContext.java diff -r a3cbdab9bd7a -r 6528c988d538 netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java --- a/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java Wed Apr 20 15:23:49 2011 -0400 +++ b/netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java Wed Apr 20 15:34:10 2011 -0400 @@ -165,7 +165,7 @@ * determined. */ protected ApplicationInstance getApplication() { - return getApplication(getClassContext(), 0); + return getApplication(Thread.currentThread(), getClassContext(), 0); } /** @@ -190,27 +190,51 @@ /** * Return the current Application, or null. */ - protected ApplicationInstance getApplication(Class stack[], int maxDepth) { + protected ApplicationInstance getApplication(Thread thread, Class stack[], int maxDepth) { + ClassLoader cl; + JNLPClassLoader jnlpCl; + + cl = thread.getContextClassLoader(); + while (cl != null) { + jnlpCl = getJnlpClassLoader(cl); + if (jnlpCl != null && jnlpCl.getApplication() != null) { + return jnlpCl.getApplication(); + } + cl = cl.getParent(); + } + if (maxDepth <= 0) maxDepth = stack.length; // this needs to be tightened up for (int i = 0; i < stack.length && i < maxDepth; i++) { - ClassLoader cl = stack[i].getClassLoader(); - - // Since we want to deal with JNLPClassLoader, extract it if this - // is a codebase loader - if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) - cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); + cl = stack[i].getClassLoader(); + while (cl != null) { + jnlpCl = getJnlpClassLoader(cl); + if (jnlpCl != null && jnlpCl.getApplication() != null) { + return jnlpCl.getApplication(); + } + cl = cl.getParent(); + } + } + return null; + } - if (cl instanceof JNLPClassLoader) { + /** + * Returns the JNLPClassLoader associated with the given ClassLoader, or + * null. + * @param cl a ClassLoader + * @return JNLPClassLoader or null + */ + private JNLPClassLoader getJnlpClassLoader(ClassLoader cl) { + // Since we want to deal with JNLPClassLoader, extract it if this + // is a codebase loader + if (cl instanceof JNLPClassLoader.CodeBaseClassLoader) + cl = ((JNLPClassLoader.CodeBaseClassLoader) cl).getParentJNLPClassLoader(); - JNLPClassLoader loader = (JNLPClassLoader) cl; - - if (loader != null && loader.getApplication() != null) { - return loader.getApplication(); - } - } + if (cl instanceof JNLPClassLoader) { + JNLPClassLoader loader = (JNLPClassLoader) cl; + return loader; } return null; @@ -444,7 +468,7 @@ } // but when they really call, stop only the app instead of the JVM - ApplicationInstance app = getApplication(stack, 0); + ApplicationInstance app = getApplication(Thread.currentThread(), stack, 0); if (app == null) { throw new SecurityException(R("RExitNoApp")); } From omajid at redhat.com Wed Apr 20 12:35:15 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 15:35:15 -0400 Subject: [icedtea-web] RFC: PR687 In-Reply-To: <20110420184739.GG12304@redhat.com> References: <4DA8753B.6040606@redhat.com> <20110420182437.GD12304@redhat.com> <4DAF278E.6050305@redhat.com> <20110420184739.GG12304@redhat.com> Message-ID: <4DAF3573.1040101@redhat.com> On 04/20/2011 02:47 PM, Deepak Bhole wrote: > * Omair Majid [2011-04-20 14:35]: >> On 04/20/2011 02:24 PM, Deepak Bhole wrote: >>> * Omair Majid [2011-04-15 12:42]: >>>> Hi, >>>> >>>> This is a (slightly updated) patch for PR687 [1]. >>>> >>>> The patch modifies how we try to find the JNLPClassLoader (from >>>> which we find the ApplicationInstance). We first search the Context >>>> ClassLoader (and it's parents) and then we search the ClassLoader >>>> for the classes on the stack (and their parents). >>>> >>> >>> Patch looks okay to me. From a security perspective, the contextloader >>> should be unique for jnlps and for applets it will only be same based on >>> the cl sharing rules which is fine (within limits of the current design). >>> >>> Btw, what is the motivation for this? Was there a case where an >>> incorrect loader was being returned off the stack? >>> >> >> In general, the implementation was incomplete - it did not take >> account of applications which used their own ClassLoader to load >> classes. Please see >> http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 for more >> details and a reproducer. >> > > Ah ok. Yeah thats what I figured too (an app creating its own loader and > spawning a new thread causing the stack being filled with those > classes). I did check out 687, couldn't find the source though, just > .class files. > > Anyway, OK for head. > Thanks for the review. I have pushed the change to HEAD. Cheers, Omair From dbhole at redhat.com Wed Apr 20 12:36:43 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 15:36:43 -0400 Subject: [icedtea-web] RFC: Use non-blocking NPN_GetURLNotify Message-ID: <20110420193643.GM12304@redhat.com> Hi, Attached patch mitigates the issue mentioned here: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013706.html This patch uses a non-blocking function to get the URL. We discard the eventual notification, but that is no different that what we do right now (we just print it currently and ignore it). For that matter, there isn't really much we _can_ do in case of load failure anyway.. ChangeLog: 2011-04-20 Deepak Bhole * plugin/icedteanp/IcedTeaNPPlugin.cc (consume_message): Use NPN_GetURLNotify (non-blocking) instead of NPN_GetURL (blocking) so that the plugin is free to process additional requests. Okay for HEAD and 1.0? Cheers, Deepak -------------- next part -------------- diff -r ad820e40fe56 plugin/icedteanp/IcedTeaNPPlugin.cc --- a/plugin/icedteanp/IcedTeaNPPlugin.cc Wed Apr 20 15:02:56 2011 -0400 +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc Wed Apr 20 15:26:03 2011 -0400 @@ -1179,7 +1179,7 @@ PLUGIN_DEBUG ("plugin_in_pipe_callback: URL target %s\n", parts[4]); NPError np_error = - (*browser_functions.geturl) (data->owner, decoded_url, parts[4]); + (*browser_functions.geturlnotify) (data->owner, decoded_url, parts[4], NULL); if (np_error != NPERR_NO_ERROR) From asu at redhat.com Wed Apr 20 12:39:13 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 15:39:13 -0400 (EDT) Subject: [rfc][icedtea-web]: Update recently_used when removing items with itw-settings In-Reply-To: <806485687.93060.1303327933076.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <46422811.93347.1303328353915.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Hello, When deleting a cached item from itw-settings recently_used would not get updated. This patch will change that behavior and update accordingly. Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: patch3.patch Type: text/x-patch Size: 1979 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/37edb6f0/patch3.patch From omajid at redhat.com Wed Apr 20 12:58:15 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 15:58:15 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <20110420192054.GL12304@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> <4DAF2F75.9010908@redhat.com> <20110420191522.GK12304@redhat.com> <4DAF318D.6030302@redhat.com> <20110420192054.GL12304@redhat.com> Message-ID: <4DAF3AD7.1020400@redhat.com> On 04/20/2011 03:20 PM, Deepak Bhole wrote: > Fair enough. Please post an updated patch with just the exception change > then and I will approve it. > Patch attached. Okay for HEAD? Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: add-new-jars-from-classpath-03.patch Type: text/x-patch Size: 7770 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/daa7fd17/add-new-jars-from-classpath-03.patch From dbhole at redhat.com Wed Apr 20 13:01:47 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 16:01:47 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <4DAF3AD7.1020400@redhat.com> References: <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> <4DAF2F75.9010908@redhat.com> <20110420191522.GK12304@redhat.com> <4DAF318D.6030302@redhat.com> <20110420192054.GL12304@redhat.com> <4DAF3AD7.1020400@redhat.com> Message-ID: <20110420200147.GN12304@redhat.com> * Omair Majid [2011-04-20 15:58]: > On 04/20/2011 03:20 PM, Deepak Bhole wrote: > >Fair enough. Please post an updated patch with just the exception change > >then and I will approve it. > > > > Patch attached. Okay for HEAD? > Yes, okay from me. Thanks, Deepak > Thanks, > Omair > diff -r 6528c988d538 netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Wed Apr 20 15:34:10 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Wed Apr 20 15:57:31 2011 -0400 > @@ -36,13 +36,16 @@ > import java.util.Collections; > import java.util.Enumeration; > import java.util.HashMap; > +import java.util.HashSet; > import java.util.LinkedList; > import java.util.List; > import java.util.Map; > +import java.util.Set; > import java.util.TreeSet; > import java.util.Vector; > import java.util.jar.JarEntry; > import java.util.jar.JarFile; > +import java.util.jar.Manifest; > > import net.sourceforge.jnlp.DownloadOptions; > import net.sourceforge.jnlp.ExtensionDesc; > @@ -138,6 +141,9 @@ > /** ArrayList containing jar indexes for various jars available to this classloader */ > private ArrayList jarIndexes = new ArrayList(); > > + /** Set of classpath strings declared in the manifest.mf files */ > + private Set classpaths = new HashSet(); > + > /** File entries in the jar files available to this classloader */ > private TreeSet jarEntries = new TreeSet(); > > @@ -766,8 +772,10 @@ > // there is currently no mechanism to cache files per > // instance.. so only index cached files > if (localFile != null) { > - JarIndex index = JarIndex.getJarIndex(new JarFile(localFile.getAbsolutePath()), > - null); > + JarFile jarFile = new JarFile(localFile.getAbsolutePath()); > + Manifest mf = jarFile.getManifest(); > + classpaths.addAll(getClassPathsFromManifest(mf, jar.getLocation().getPath())); > + JarIndex index = JarIndex.getJarIndex(jarFile, null); > if (index != null) > jarIndexes.add(index); > } > @@ -1008,8 +1016,30 @@ > try { > result = loadClassExt(name); > } catch (ClassNotFoundException cnfe) { > + // Not found in external loader either > > - // Not found in external loader either. As a last resort, look in any available indexes > + // Look in 'Class-Path' as specified in the manifest file > + try { > + for (String classpath: classpaths) { > + JARDesc desc; > + try { > + URL jarUrl = new URL(file.getCodeBase(), classpath); > + desc = new JARDesc(jarUrl, null, null, false, true, false, true); > + } catch (MalformedURLException mfe) { > + throw new ClassNotFoundException(name, mfe); > + } > + addNewJar(desc); > + } > + > + result = loadClassExt(name); > + return result; > + } catch (ClassNotFoundException cnfe1) { > + if (JNLPRuntime.isDebug()) { > + cnfe1.printStackTrace(); > + } > + } > + > + // As a last resort, look in any available indexes > > // Currently this loads jars directly from the site. We cannot cache it because this > // call is initiated from within the applet, which does not have disk read/write permissions > @@ -1027,33 +1057,13 @@ > } catch (MalformedURLException mfe) { > throw new ClassNotFoundException(name); > } > - > - available.add(desc); > - > - tracker.addResource(desc.getLocation(), > - desc.getVersion(), > - null, > - JNLPRuntime.getDefaultUpdatePolicy() > - ); > - > - URL remoteURL; > try { > - remoteURL = new URL(file.getCodeBase() + jarName); > - } catch (MalformedURLException mfe) { > - throw new ClassNotFoundException(name); > + addNewJar(desc); > + } catch (Exception e) { > + if (JNLPRuntime.isDebug()) { > + e.printStackTrace(); > + } > } > - > - URL u; > - > - try { > - u = tracker.getCacheURL(remoteURL); > - } catch (Exception e) { > - throw new ClassNotFoundException(name); > - } > - > - if (u != null) > - addURL(u); > - > } > > // If it still fails, let it error out > @@ -1071,6 +1081,31 @@ > } > > /** > + * Adds a new JARDesc into this classloader. > + *

> + * This will add the JARDesc into the resourceTracker and block until it > + * is downloaded. > + * @param desc the JARDesc for the new jar > + */ > + private void addNewJar(JARDesc desc) { > + > + available.add(desc); > + > + tracker.addResource(desc.getLocation(), > + desc.getVersion(), > + null, > + JNLPRuntime.getDefaultUpdatePolicy() > + ); > + > + URL remoteURL = desc.getLocation(); > + > + URL u = tracker.getCacheURL(remoteURL); > + if (u != null) { > + addURL(u); > + } > + } > + > + /** > * Find the class in this loader or any of its extension loaders. > */ > protected Class findClass(String name) throws ClassNotFoundException { > @@ -1325,6 +1360,41 @@ > return file.getDownloadOptionsForJar(jar); > } > > + /** > + * Returns a set of paths that indicate the Class-Path entries in the > + * manifest file. The paths are rooted in the same directory as the > + * originalJarPath. > + * @param mf the manifest > + * @param originalJarPath the remote/original path of the jar containing > + * the manifest > + * @return a Set of String where each string is a path to the jar on > + * the original jar's classpath. > + */ > + private Set getClassPathsFromManifest(Manifest mf, String originalJarPath) { > + Set result = new HashSet(); > + if (mf != null) { > + // extract the Class-Path entries from the manifest and split them > + String classpath = mf.getMainAttributes().getValue("Class-Path"); > + String[] paths = classpath.split(" +"); > + for (String path : paths) { > + if (path.trim().length() == 0) { > + continue; > + } > + // we want to search for jars in the same subdir on the server > + // as the original jar that contains the manifest file, so find > + // out its subdirectory and use that as the dir > + String dir = ""; > + int lastSlash = originalJarPath.lastIndexOf("/"); > + if (lastSlash != -1) { > + dir = originalJarPath.substring(0, lastSlash + 1); > + } > + String fullPath = dir + path; > + result.add(fullPath); > + } > + } > + return result; > + } > + > /* > * Helper class to expose protected URLClassLoader methods. > */ From dbhole at redhat.com Wed Apr 20 13:06:52 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 16:06:52 -0400 Subject: [rfc][icedtea-web]: Update recently_used when removing items with itw-settings In-Reply-To: <46422811.93347.1303328353915.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <806485687.93060.1303327933076.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <46422811.93347.1303328353915.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110420200652.GO12304@redhat.com> * Andrew Su [2011-04-20 15:40]: > Hello, > > When deleting a cached item from itw-settings recently_used would not get updated. > This patch will change that behavior and update accordingly. > Please post changelogs with all your patches in the future. What happens is delete fails for some reason? Wouldn't the entry get removed incorrectly and become untracked? Also, I noticed that the code below is doing this: if (fileNode.getFile().delete()) { fileNode.getParent().removeChild(fileNode); FileUtils.deleteWithErrMesg(fileNode.getInfoFile()); ... Isn't the last line trying to re-delete the file? Cheers, Deepak > Cheers, > Andrew > diff -r ad820e40fe56 netx/net/sourceforge/jnlp/controlpanel/CachePane.java > --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 15:02:56 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 15:31:12 2011 -0400 > @@ -32,6 +32,7 @@ > import java.nio.channels.FileLock; > import java.text.SimpleDateFormat; > import java.util.ArrayList; > +import java.util.Enumeration; > import java.util.List; > > import javax.swing.JButton; > @@ -48,6 +49,7 @@ > import net.sourceforge.jnlp.config.DeploymentConfiguration; > import net.sourceforge.jnlp.runtime.Translator; > import net.sourceforge.jnlp.util.FileUtils; > +import net.sourceforge.jnlp.util.PropertiesFile; > > public class CachePane extends JPanel { > > @@ -152,6 +154,9 @@ > return; > int modelRow = cacheTable.convertRowIndexToModel(row); > DirectoryNode fileNode = ((DirectoryNode) cacheTable.getModel().getValueAt(modelRow, 0)); > + > + updateRecentlyUsed(fileNode.getFile()); > + > if (fileNode.getFile().delete()) { > fileNode.getParent().removeChild(fileNode); > FileUtils.deleteWithErrMesg(fileNode.getInfoFile()); > @@ -172,6 +177,20 @@ > } > } > } > + > + private void updateRecentlyUsed(File f) { > + File recentlyUsedFile = new File(location + File.separator + "recently_used"); > + PropertiesFile pf = new PropertiesFile(recentlyUsedFile); > + pf.load(); > + Enumeration en = pf.keys(); > + while (en.hasMoreElements()) { > + String key = (String) en.nextElement(); > + if (pf.get(key).equals(f.getAbsolutePath())) { > + pf.remove(key); > + } > + } > + pf.store(); > + } > }); > buttons.add(deleteButton); > From dbhole at redhat.com Wed Apr 20 13:08:53 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 16:08:53 -0400 Subject: [icedtea-web] RFC: Use non-blocking NPN_GetURLNotify In-Reply-To: <20110420193643.GM12304@redhat.com> References: <20110420193643.GM12304@redhat.com> Message-ID: <20110420200853.GP12304@redhat.com> This one didn't appear in my inbox :/ re-sending... * Deepak Bhole [2011-04-20 15:36]: > Hi, > > Attached patch mitigates the issue mentioned here: > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013706.html > > This patch uses a non-blocking function to get the URL. We discard the > eventual notification, but that is no different that what we do right now > (we just print it currently and ignore it). For that matter, there isn't > really much we _can_ do in case of load failure anyway.. > > ChangeLog: > 2011-04-20 Deepak Bhole > > * plugin/icedteanp/IcedTeaNPPlugin.cc (consume_message): Use > NPN_GetURLNotify (non-blocking) instead of NPN_GetURL (blocking) so that > the plugin is free to process additional requests. > > Okay for HEAD and 1.0? > > Cheers, > Deepak > diff -r ad820e40fe56 plugin/icedteanp/IcedTeaNPPlugin.cc > --- a/plugin/icedteanp/IcedTeaNPPlugin.cc Wed Apr 20 15:02:56 2011 -0400 > +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc Wed Apr 20 15:26:03 2011 -0400 > @@ -1179,7 +1179,7 @@ > PLUGIN_DEBUG ("plugin_in_pipe_callback: URL target %s\n", parts[4]); > > NPError np_error = > - (*browser_functions.geturl) (data->owner, decoded_url, parts[4]); > + (*browser_functions.geturlnotify) (data->owner, decoded_url, parts[4], NULL); > > > if (np_error != NPERR_NO_ERROR) From omajid at icedtea.classpath.org Wed Apr 20 13:33:40 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Wed, 20 Apr 2011 20:33:40 +0000 Subject: /hg/icedtea-web: Load classes from jars listed on the Class-Path... Message-ID: changeset 6abf7a788f4e in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=6abf7a788f4e author: Omair Majid date: Wed Apr 20 16:33:18 2011 -0400 Load classes from jars listed on the Class-Path in manifest An applet the demonstrates the bug is located at http://jung.sourceforge.net/applet/showlayouts2.html diffstat: ChangeLog | 10 + netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java | 126 +++++++++++++--- 2 files changed, 108 insertions(+), 28 deletions(-) diffs (205 lines): diff -r 6528c988d538 -r 6abf7a788f4e ChangeLog --- a/ChangeLog Wed Apr 20 15:34:10 2011 -0400 +++ b/ChangeLog Wed Apr 20 16:33:18 2011 -0400 @@ -1,3 +1,13 @@ +2011-04-20 Omair Majid + + * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: Add new private + variable classpathsInManifest. + (activateJars): When adding jar index, also add Class-Path entries from the + Manifest file in the jar. + (loadClass): Search for jars specified in classpaths before looking for + entries in jar index. + (addNewJar): New method refactored from loadClass. + 2011-04-20 Omair Majid * netx/net/sourceforge/jnlp/runtime/JNLPSecurityManager.java diff -r 6528c988d538 -r 6abf7a788f4e netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Wed Apr 20 15:34:10 2011 -0400 +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Wed Apr 20 16:33:18 2011 -0400 @@ -36,13 +36,16 @@ import java.util.Collections; import java.util.Enumeration; import java.util.HashMap; +import java.util.HashSet; import java.util.LinkedList; import java.util.List; import java.util.Map; +import java.util.Set; import java.util.TreeSet; import java.util.Vector; import java.util.jar.JarEntry; import java.util.jar.JarFile; +import java.util.jar.Manifest; import net.sourceforge.jnlp.DownloadOptions; import net.sourceforge.jnlp.ExtensionDesc; @@ -138,6 +141,9 @@ /** ArrayList containing jar indexes for various jars available to this classloader */ private ArrayList jarIndexes = new ArrayList(); + /** Set of classpath strings declared in the manifest.mf files */ + private Set classpaths = new HashSet(); + /** File entries in the jar files available to this classloader */ private TreeSet jarEntries = new TreeSet(); @@ -766,8 +772,10 @@ // there is currently no mechanism to cache files per // instance.. so only index cached files if (localFile != null) { - JarIndex index = JarIndex.getJarIndex(new JarFile(localFile.getAbsolutePath()), - null); + JarFile jarFile = new JarFile(localFile.getAbsolutePath()); + Manifest mf = jarFile.getManifest(); + classpaths.addAll(getClassPathsFromManifest(mf, jar.getLocation().getPath())); + JarIndex index = JarIndex.getJarIndex(jarFile, null); if (index != null) jarIndexes.add(index); } @@ -1008,8 +1016,30 @@ try { result = loadClassExt(name); } catch (ClassNotFoundException cnfe) { + // Not found in external loader either - // Not found in external loader either. As a last resort, look in any available indexes + // Look in 'Class-Path' as specified in the manifest file + try { + for (String classpath: classpaths) { + JARDesc desc; + try { + URL jarUrl = new URL(file.getCodeBase(), classpath); + desc = new JARDesc(jarUrl, null, null, false, true, false, true); + } catch (MalformedURLException mfe) { + throw new ClassNotFoundException(name, mfe); + } + addNewJar(desc); + } + + result = loadClassExt(name); + return result; + } catch (ClassNotFoundException cnfe1) { + if (JNLPRuntime.isDebug()) { + cnfe1.printStackTrace(); + } + } + + // As a last resort, look in any available indexes // Currently this loads jars directly from the site. We cannot cache it because this // call is initiated from within the applet, which does not have disk read/write permissions @@ -1027,33 +1057,13 @@ } catch (MalformedURLException mfe) { throw new ClassNotFoundException(name); } - - available.add(desc); - - tracker.addResource(desc.getLocation(), - desc.getVersion(), - null, - JNLPRuntime.getDefaultUpdatePolicy() - ); - - URL remoteURL; try { - remoteURL = new URL(file.getCodeBase() + jarName); - } catch (MalformedURLException mfe) { - throw new ClassNotFoundException(name); + addNewJar(desc); + } catch (Exception e) { + if (JNLPRuntime.isDebug()) { + e.printStackTrace(); + } } - - URL u; - - try { - u = tracker.getCacheURL(remoteURL); - } catch (Exception e) { - throw new ClassNotFoundException(name); - } - - if (u != null) - addURL(u); - } // If it still fails, let it error out @@ -1071,6 +1081,31 @@ } /** + * Adds a new JARDesc into this classloader. + *

+ * This will add the JARDesc into the resourceTracker and block until it + * is downloaded. + * @param desc the JARDesc for the new jar + */ + private void addNewJar(JARDesc desc) { + + available.add(desc); + + tracker.addResource(desc.getLocation(), + desc.getVersion(), + null, + JNLPRuntime.getDefaultUpdatePolicy() + ); + + URL remoteURL = desc.getLocation(); + + URL u = tracker.getCacheURL(remoteURL); + if (u != null) { + addURL(u); + } + } + + /** * Find the class in this loader or any of its extension loaders. */ protected Class findClass(String name) throws ClassNotFoundException { @@ -1325,6 +1360,41 @@ return file.getDownloadOptionsForJar(jar); } + /** + * Returns a set of paths that indicate the Class-Path entries in the + * manifest file. The paths are rooted in the same directory as the + * originalJarPath. + * @param mf the manifest + * @param originalJarPath the remote/original path of the jar containing + * the manifest + * @return a Set of String where each string is a path to the jar on + * the original jar's classpath. + */ + private Set getClassPathsFromManifest(Manifest mf, String originalJarPath) { + Set result = new HashSet(); + if (mf != null) { + // extract the Class-Path entries from the manifest and split them + String classpath = mf.getMainAttributes().getValue("Class-Path"); + String[] paths = classpath.split(" +"); + for (String path : paths) { + if (path.trim().length() == 0) { + continue; + } + // we want to search for jars in the same subdir on the server + // as the original jar that contains the manifest file, so find + // out its subdirectory and use that as the dir + String dir = ""; + int lastSlash = originalJarPath.lastIndexOf("/"); + if (lastSlash != -1) { + dir = originalJarPath.substring(0, lastSlash + 1); + } + String fullPath = dir + path; + result.add(fullPath); + } + } + return result; + } + /* * Helper class to expose protected URLClassLoader methods. */ From omajid at redhat.com Wed Apr 20 13:34:56 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 20 Apr 2011 16:34:56 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <20110420200147.GN12304@redhat.com> References: <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> <4DAF2F75.9010908@redhat.com> <20110420191522.GK12304@redhat.com> <4DAF318D.6030302@redhat.com> <20110420192054.GL12304@redhat.com> <4DAF3AD7.1020400@redhat.com> <20110420200147.GN12304@redhat.com> Message-ID: <4DAF4370.3060400@redhat.com> On 04/20/2011 04:01 PM, Deepak Bhole wrote: > * Omair Majid [2011-04-20 15:58]: >> On 04/20/2011 03:20 PM, Deepak Bhole wrote: >>> Fair enough. Please post an updated patch with just the exception change >>> then and I will approve it. >>> >> >> Patch attached. Okay for HEAD? >> > > Yes, okay from me. > Thanks. I have pushed the change. Cheers, Omair From asu at redhat.com Wed Apr 20 13:45:11 2011 From: asu at redhat.com (Andrew Su) Date: Wed, 20 Apr 2011 16:45:11 -0400 (EDT) Subject: [rfc][icedtea-web]: Update recently_used when removing items with itw-settings In-Reply-To: <20110420200652.GO12304@redhat.com> Message-ID: <242804021.94839.1303332311544.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Deepak Bhole" > To: "Andrew Su" > Cc: "IcedTea" > Sent: Wednesday, April 20, 2011 4:06:52 PM > Subject: Re: [rfc][icedtea-web]: Update recently_used when removing items with itw-settings > * Andrew Su [2011-04-20 15:40]: > > Hello, > > > > When deleting a cached item from itw-settings recently_used would > > not get updated. > > This patch will change that behavior and update accordingly. > > > > Please post changelogs with all your patches in the future. ah ok. > > What happens is delete fails for some reason? Wouldn't the entry get > removed incorrectly and become untracked? I've moved the removing entry from our lru to be called only after a delete succeeds. If for any other reason that delete fails we can ignore it (or maybe inform the user). > > Also, I noticed that the code below is doing this: > if (fileNode.getFile().delete()) { > fileNode.getParent().removeChild(fileNode); > FileUtils.deleteWithErrMesg(fileNode.getInfoFile()); > ... > > Isn't the last line trying to re-delete the file? > The last line is to delete the info file associated with the entry. ChangeLog: 2011-04-20 Andrew Su * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: (createButtonPanel): Changed to update the recently_used file to reflect the deletion. Added method updateRecentlyUsed to anonymous ActionListener class which will do the actual updating. > Cheers, > Deepak > > > Cheers, > > Andrew > > > diff -r ad820e40fe56 > > netx/net/sourceforge/jnlp/controlpanel/CachePane.java > > --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr > > 20 15:02:56 2011 -0400 > > +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr > > 20 15:31:12 2011 -0400 > > @@ -32,6 +32,7 @@ > > import java.nio.channels.FileLock; > > import java.text.SimpleDateFormat; > > import java.util.ArrayList; > > +import java.util.Enumeration; > > import java.util.List; > > > > import javax.swing.JButton; > > @@ -48,6 +49,7 @@ > > import net.sourceforge.jnlp.config.DeploymentConfiguration; > > import net.sourceforge.jnlp.runtime.Translator; > > import net.sourceforge.jnlp.util.FileUtils; > > +import net.sourceforge.jnlp.util.PropertiesFile; > > > > public class CachePane extends JPanel { > > > > @@ -152,6 +154,9 @@ > > return; > > int modelRow = > > cacheTable.convertRowIndexToModel(row); > > DirectoryNode fileNode = ((DirectoryNode) > > cacheTable.getModel().getValueAt(modelRow, 0)); > > + > > + updateRecentlyUsed(fileNode.getFile()); > > + > > if (fileNode.getFile().delete()) { > > fileNode.getParent().removeChild(fileNode); > > FileUtils.deleteWithErrMesg(fileNode.getInfoFile()); > > @@ -172,6 +177,20 @@ > > } > > } > > } > > + > > + private void updateRecentlyUsed(File f) { > > + File recentlyUsedFile = new File(location + File.separator + > > "recently_used"); > > + PropertiesFile pf = new PropertiesFile(recentlyUsedFile); > > + pf.load(); > > + Enumeration en = pf.keys(); > > + while (en.hasMoreElements()) { > > + String key = (String) en.nextElement(); > > + if (pf.get(key).equals(f.getAbsolutePath())) { > > + pf.remove(key); > > + } > > + } > > + pf.store(); > > + } > > }); > > buttons.add(deleteButton); > > -------------- next part -------------- A non-text attachment was scrubbed... Name: patch4.patch Type: text/x-patch Size: 2036 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110420/04a887b8/patch4.patch From dbhole at redhat.com Wed Apr 20 13:49:40 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 16:49:40 -0400 Subject: [rfc][icedtea-web]: Update recently_used when removing items with itw-settings In-Reply-To: <242804021.94839.1303332311544.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <20110420200652.GO12304@redhat.com> <242804021.94839.1303332311544.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110420204939.GQ12304@redhat.com> * Andrew Su [2011-04-20 16:45]: > > > ----- Original Message ----- > > From: "Deepak Bhole" > > To: "Andrew Su" > > Cc: "IcedTea" > > Sent: Wednesday, April 20, 2011 4:06:52 PM > > Subject: Re: [rfc][icedtea-web]: Update recently_used when removing items with itw-settings > > * Andrew Su [2011-04-20 15:40]: > > > Hello, > > > > > > When deleting a cached item from itw-settings recently_used would > > > not get updated. > > > This patch will change that behavior and update accordingly. > > > > > > > Please post changelogs with all your patches in the future. > > ah ok. > > > > > What happens is delete fails for some reason? Wouldn't the entry get > > removed incorrectly and become untracked? > > I've moved the removing entry from our lru to be called only after a delete succeeds. If for any other reason that delete fails we can ignore it (or maybe inform the user). > > > > > Also, I noticed that the code below is doing this: > > if (fileNode.getFile().delete()) { > > fileNode.getParent().removeChild(fileNode); > > FileUtils.deleteWithErrMesg(fileNode.getInfoFile()); > > ... > > > > Isn't the last line trying to re-delete the file? > > > > The last line is to delete the info file associated with the entry. > Doh, sorry, missed that. Okay, patch looks good. OK for head. Cheers, Deepak > > ChangeLog: > 2011-04-20 Andrew Su > > * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: > (createButtonPanel): Changed to update the recently_used file to > reflect the deletion. Added method updateRecentlyUsed to anonymous > ActionListener class which will do the actual updating. > > > Cheers, > > Deepak > > > > > Cheers, > > > Andrew > > > > > diff -r ad820e40fe56 > > > netx/net/sourceforge/jnlp/controlpanel/CachePane.java > > > --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr > > > 20 15:02:56 2011 -0400 > > > +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr > > > 20 15:31:12 2011 -0400 > > > @@ -32,6 +32,7 @@ > > > import java.nio.channels.FileLock; > > > import java.text.SimpleDateFormat; > > > import java.util.ArrayList; > > > +import java.util.Enumeration; > > > import java.util.List; > > > > > > import javax.swing.JButton; > > > @@ -48,6 +49,7 @@ > > > import net.sourceforge.jnlp.config.DeploymentConfiguration; > > > import net.sourceforge.jnlp.runtime.Translator; > > > import net.sourceforge.jnlp.util.FileUtils; > > > +import net.sourceforge.jnlp.util.PropertiesFile; > > > > > > public class CachePane extends JPanel { > > > > > > @@ -152,6 +154,9 @@ > > > return; > > > int modelRow = > > > cacheTable.convertRowIndexToModel(row); > > > DirectoryNode fileNode = ((DirectoryNode) > > > cacheTable.getModel().getValueAt(modelRow, 0)); > > > + > > > + updateRecentlyUsed(fileNode.getFile()); > > > + > > > if (fileNode.getFile().delete()) { > > > fileNode.getParent().removeChild(fileNode); > > > FileUtils.deleteWithErrMesg(fileNode.getInfoFile()); > > > @@ -172,6 +177,20 @@ > > > } > > > } > > > } > > > + > > > + private void updateRecentlyUsed(File f) { > > > + File recentlyUsedFile = new File(location + File.separator + > > > "recently_used"); > > > + PropertiesFile pf = new PropertiesFile(recentlyUsedFile); > > > + pf.load(); > > > + Enumeration en = pf.keys(); > > > + while (en.hasMoreElements()) { > > > + String key = (String) en.nextElement(); > > > + if (pf.get(key).equals(f.getAbsolutePath())) { > > > + pf.remove(key); > > > + } > > > + } > > > + pf.store(); > > > + } > > > }); > > > buttons.add(deleteButton); > > > > diff -r ad820e40fe56 netx/net/sourceforge/jnlp/controlpanel/CachePane.java > --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 15:02:56 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 16:42:49 2011 -0400 > @@ -32,6 +32,7 @@ > import java.nio.channels.FileLock; > import java.text.SimpleDateFormat; > import java.util.ArrayList; > +import java.util.Enumeration; > import java.util.List; > > import javax.swing.JButton; > @@ -48,6 +49,7 @@ > import net.sourceforge.jnlp.config.DeploymentConfiguration; > import net.sourceforge.jnlp.runtime.Translator; > import net.sourceforge.jnlp.util.FileUtils; > +import net.sourceforge.jnlp.util.PropertiesFile; > > public class CachePane extends JPanel { > > @@ -153,6 +155,7 @@ > int modelRow = cacheTable.convertRowIndexToModel(row); > DirectoryNode fileNode = ((DirectoryNode) cacheTable.getModel().getValueAt(modelRow, 0)); > if (fileNode.getFile().delete()) { > + updateRecentlyUsed(fileNode.getFile()); > fileNode.getParent().removeChild(fileNode); > FileUtils.deleteWithErrMesg(fileNode.getInfoFile()); > ((DefaultTableModel) cacheTable.getModel()).removeRow(modelRow); > @@ -172,6 +175,20 @@ > } > } > } > + > + private void updateRecentlyUsed(File f) { > + File recentlyUsedFile = new File(location + File.separator + "recently_used"); > + PropertiesFile pf = new PropertiesFile(recentlyUsedFile); > + pf.load(); > + Enumeration en = pf.keys(); > + while (en.hasMoreElements()) { > + String key = (String) en.nextElement(); > + if (pf.get(key).equals(f.getAbsolutePath())) { > + pf.remove(key); > + } > + } > + pf.store(); > + } > }); > buttons.add(deleteButton); > From asu at icedtea.classpath.org Wed Apr 20 13:56:49 2011 From: asu at icedtea.classpath.org (asu at icedtea.classpath.org) Date: Wed, 20 Apr 2011 20:56:49 +0000 Subject: /hg/icedtea-web: Update recently_used when deleting cache entrie... Message-ID: changeset a50cd6a66ae6 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=a50cd6a66ae6 author: Andrew Su date: Wed Apr 20 16:58:29 2011 -0400 Update recently_used when deleting cache entries with itw-settings diffstat: ChangeLog | 7 +++++++ netx/net/sourceforge/jnlp/controlpanel/CachePane.java | 17 +++++++++++++++++ 2 files changed, 24 insertions(+), 0 deletions(-) diffs (62 lines): diff -r 6abf7a788f4e -r a50cd6a66ae6 ChangeLog --- a/ChangeLog Wed Apr 20 16:33:18 2011 -0400 +++ b/ChangeLog Wed Apr 20 16:58:29 2011 -0400 @@ -1,3 +1,10 @@ +2011-04-20 Andrew Su + + * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: + (createButtonPanel): Changed to update the recently_used file to + reflect the deletion. Added method updateRecentlyUsed to anonymous + ActionListener class which will do the actual updating. + 2011-04-20 Omair Majid * netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java: Add new private diff -r 6abf7a788f4e -r a50cd6a66ae6 netx/net/sourceforge/jnlp/controlpanel/CachePane.java --- a/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 16:33:18 2011 -0400 +++ b/netx/net/sourceforge/jnlp/controlpanel/CachePane.java Wed Apr 20 16:58:29 2011 -0400 @@ -32,6 +32,7 @@ import java.nio.channels.FileLock; import java.text.SimpleDateFormat; import java.util.ArrayList; +import java.util.Enumeration; import java.util.List; import javax.swing.JButton; @@ -48,6 +49,7 @@ import net.sourceforge.jnlp.config.DeploymentConfiguration; import net.sourceforge.jnlp.runtime.Translator; import net.sourceforge.jnlp.util.FileUtils; +import net.sourceforge.jnlp.util.PropertiesFile; public class CachePane extends JPanel { @@ -153,6 +155,7 @@ int modelRow = cacheTable.convertRowIndexToModel(row); DirectoryNode fileNode = ((DirectoryNode) cacheTable.getModel().getValueAt(modelRow, 0)); if (fileNode.getFile().delete()) { + updateRecentlyUsed(fileNode.getFile()); fileNode.getParent().removeChild(fileNode); FileUtils.deleteWithErrMesg(fileNode.getInfoFile()); ((DefaultTableModel) cacheTable.getModel()).removeRow(modelRow); @@ -172,6 +175,20 @@ } } } + + private void updateRecentlyUsed(File f) { + File recentlyUsedFile = new File(location + File.separator + "recently_used"); + PropertiesFile pf = new PropertiesFile(recentlyUsedFile); + pf.load(); + Enumeration en = pf.keys(); + while (en.hasMoreElements()) { + String key = (String) en.nextElement(); + if (pf.get(key).equals(f.getAbsolutePath())) { + pf.remove(key); + } + } + pf.store(); + } }); buttons.add(deleteButton); From ahughes at redhat.com Wed Apr 20 15:31:12 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 23:31:12 +0100 Subject: RFC: PR690: Shark fails to JIT using hs20 In-Reply-To: <4DAEB54F.2060806@zafena.se> References: <4DAEB54F.2060806@zafena.se> Message-ID: <20110420223111.GT29985@rivendell.middle-earth.co.uk> On 12:28 Wed 20 Apr , Xerxes R?nby wrote: > Hi the attached patches updates icedtea6-1.10 and icedtea6 trunk to make the Shark JIT work when using HotSpot 20 and later: > > Before: > #Shark built against hs20 fails to JIT. > icedtea6-shark/openjdk.build/j2sdk-image/bin/java -version > java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.11pre+r0239a181c7a0+) (Ubuntu build > 1.6.0_22-b22) > OpenJDK Shark VM (build 20.0-b11, mixed mode) > xerxes at xerxes-J464X:~/cm30$ > ../icedtea6-shark/openjdk.build/j2sdk-image/bin/java CaffeineMarkEmbeddedApp > Sieve score = 2648 (98) > Loop score = 1746 (2017) > Logic score = 2459 (0) > String score = 4048 (708) > Float score = 1836 (185) > Method score = 1490 (166650) > Overall score = 2238 > > After: > xerxes at xerxes-J464X:~/cm30$ ../icedtea6-shark-hs/openjdk.build/j2sdk-image/binava -showversion CaffeineMarkEmbeddedApp > java version "1.6.0_22" > OpenJDK Runtime Environment (IcedTea6 1.11pre+r307d19e0cca0+) (Ubuntu build 1.6.0_22-b22) > OpenJDK Shark VM (build 20.0-b11, mixed mode) > > Sieve score = 39462 (98) > Loop score = 54003 (2017) > Logic score = 71066 (0) > String score = 26256 (708) > Float score = 33218 (185) > Method score = 21011 (166650) > Overall score = 37487 > > > I have tested these patches using the following three configurations: > > ../icedtea6-1.10/configure --enable-shark --disable-bootstrap --disable-docs --with-hotspot-build > > ../icedtea6/configure --enable-shark --disable-docs --disable-bootstrap > ../icedtea6/configure --enable-shark --disable-bootstrap --disable-docs --with-hotspot-build > > > Ok to push to IcedTea6-1.10 release branch? > > Ok to push to IcedTea6 trunk? > > Cheers > Xerxes What part of 7032458 is being used here? I'm concerned that neither the NEWS item nor the patch file mention 7032458. Are there parts of 7032458 that don't apply? The patch claims to be for hs20 but you seem to be applying it unconditionally (and thus for hs19 too). > Index: icedtea6/Makefile.am > =================================================================== > --- icedtea6.orig/Makefile.am 2011-04-20 11:39:13.640753000 +0200 > +++ icedtea6/Makefile.am 2011-04-20 11:39:55.248753002 +0200 > @@ -336,7 +336,8 @@ > patches/revert-6885123.patch \ > patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ > patches/openjdk/7031385-gcc-register-allocation-fix.patch \ > - patches/shark-llvm-2.9.patch > + patches/shark-llvm-2.9.patch \ > + patches/pr690-shark-jit-hs20.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ > Index: icedtea6/patches/pr690-shark-jit-hs20.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6/patches/pr690-shark-jit-hs20.patch 2011-04-20 11:39:01.520753016 +0200 > @@ -0,0 +1,61 @@ > +Index: openjdk/hotspot/src/share/vm/shark/sharkCompiler.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/shark/sharkCompiler.hpp 2011-04-15 14:48:22.175181000 +0200 > ++++ openjdk/hotspot/src/share/vm/shark/sharkCompiler.hpp 2011-04-15 16:19:28.915181000 +0200 > +@@ -113,7 +113,7 @@ > + // Global access > + public: > + static SharkCompiler* compiler() { > +- AbstractCompiler *compiler = CompileBroker::compiler(CompLevel_simple); > ++ AbstractCompiler *compiler = CompileBroker::compiler(CompLevel_full_optimization); > + assert(compiler->is_shark() && compiler->is_initialized(), "should be"); > + return (SharkCompiler *) compiler; > + } > +Index: openjdk/hotspot/src/share/vm/utilities/globalDefinitions.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/utilities/globalDefinitions.hpp 2011-04-15 14:54:00.447181000 +0200 > ++++ openjdk/hotspot/src/share/vm/utilities/globalDefinitions.hpp 2011-04-15 15:02:25.851181000 +0200 > +@@ -740,9 +740,9 @@ > + CompLevel_simple = 1, // C1 > + CompLevel_limited_profile = 2, // C1, invocation & backedge counters > + CompLevel_full_profile = 3, // C1, invocation & backedge counters + mdo > +- CompLevel_full_optimization = 4, // C2 > ++ CompLevel_full_optimization = 4, // C2 or Shark > + > +-#if defined(COMPILER2) > ++#if defined(COMPILER2) || defined(SHARK) > + CompLevel_highest_tier = CompLevel_full_optimization, // pure C2 and tiered > + #elif defined(COMPILER1) > + CompLevel_highest_tier = CompLevel_simple, // pure C1 > +@@ -754,7 +754,7 @@ > + CompLevel_initial_compile = CompLevel_full_profile // tiered > + #elif defined(COMPILER1) > + CompLevel_initial_compile = CompLevel_simple // pure C1 > +-#elif defined(COMPILER2) > ++#elif defined(COMPILER2) || defined(SHARK) > + CompLevel_initial_compile = CompLevel_full_optimization // pure C2 > + #else > + CompLevel_initial_compile = CompLevel_none > +Index: openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/compiler/compileBroker.cpp 2011-04-15 16:05:50.051181001 +0200 > ++++ openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp 2011-04-15 16:08:46.127181000 +0200 > +@@ -768,7 +768,9 @@ > + // Initialize the compilation queue > + void CompileBroker::init_compiler_threads(int c1_compiler_count, int c2_compiler_count) { > + EXCEPTION_MARK; > ++#if !defined(ZERO) && !defined(SHARK) > + assert(c2_compiler_count > 0 || c1_compiler_count > 0, "No compilers?"); > ++#endif // !ZERO && !SHARK > + if (c2_compiler_count > 0) { > + _c2_method_queue = new CompileQueue("C2MethodQueue", MethodCompileQueue_lock); > + } > +@@ -1029,7 +1031,7 @@ > + > + assert(!HAS_PENDING_EXCEPTION, "No exception should be present"); > + // some prerequisites that are compiler specific > +- if (compiler(comp_level)->is_c2()) { > ++ if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_shark()) { > + method->constants()->resolve_string_constants(CHECK_0); > + // Resolve all classes seen in the signature of the method > + // we are compiling. > Index: icedtea6/ChangeLog > =================================================================== > --- icedtea6.orig/ChangeLog 2011-04-20 11:56:57.852753002 +0200 > +++ icedtea6/ChangeLog 2011-04-20 11:57:34.420753002 +0200 > @@ -1,3 +1,11 @@ > +2011-04-20 Xerxes R??nby > + > + PR690: Shark fails to JIT using hs20 > + * Makefile.am: Add patch > + * patches/pr690-shark-jit-hs20.patch: > + Backported Shark fixes from OpenJDK bug 7032458. > + * NEWS: Updated. > + > 2011-04-12 Xerxes R??nby > > PR689: Shark fails to find LLVM 2.9 System headers during build > Index: icedtea6/NEWS > =================================================================== > --- icedtea6.orig/NEWS 2011-04-20 11:54:46.900753002 +0200 > +++ icedtea6/NEWS 2011-04-20 11:56:10.648753002 +0200 > @@ -48,6 +48,7 @@ > - Trivial implementation of stubs for MIPS. > * Shark > - PR689: Shark fails to find LLVM 2.9 System headers during build. > + - PR690: Shark fails to JIT using hs20. > > New in release 1.10 (2011-XX-XX): > > Index: icedtea6-1.10/Makefile.am > =================================================================== > --- icedtea6-1.10.orig/Makefile.am 2011-04-20 11:42:37.816753001 +0200 > +++ icedtea6-1.10/Makefile.am 2011-04-20 11:44:13.344753002 +0200 > @@ -335,6 +335,7 @@ > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ > patches/pr639-broken_shark_build.patch \ > + patches/pr690-shark-jit-hs20.patch \ > patches/hotspot/$(HSBUILD)/powerpc-stacksize.patch > else > ICEDTEA_PATCHES += \ > Index: icedtea6-1.10/patches/pr690-shark-jit-hs20.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6-1.10/patches/pr690-shark-jit-hs20.patch 2011-04-20 11:43:11.420753001 +0200 > @@ -0,0 +1,61 @@ > +Index: openjdk/hotspot/src/share/vm/shark/sharkCompiler.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/shark/sharkCompiler.hpp 2011-04-15 14:48:22.175181000 +0200 > ++++ openjdk/hotspot/src/share/vm/shark/sharkCompiler.hpp 2011-04-15 16:19:28.915181000 +0200 > +@@ -113,7 +113,7 @@ > + // Global access > + public: > + static SharkCompiler* compiler() { > +- AbstractCompiler *compiler = CompileBroker::compiler(CompLevel_simple); > ++ AbstractCompiler *compiler = CompileBroker::compiler(CompLevel_full_optimization); > + assert(compiler->is_shark() && compiler->is_initialized(), "should be"); > + return (SharkCompiler *) compiler; > + } > +Index: openjdk/hotspot/src/share/vm/utilities/globalDefinitions.hpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/utilities/globalDefinitions.hpp 2011-04-15 14:54:00.447181000 +0200 > ++++ openjdk/hotspot/src/share/vm/utilities/globalDefinitions.hpp 2011-04-15 15:02:25.851181000 +0200 > +@@ -740,9 +740,9 @@ > + CompLevel_simple = 1, // C1 > + CompLevel_limited_profile = 2, // C1, invocation & backedge counters > + CompLevel_full_profile = 3, // C1, invocation & backedge counters + mdo > +- CompLevel_full_optimization = 4, // C2 > ++ CompLevel_full_optimization = 4, // C2 or Shark > + > +-#if defined(COMPILER2) > ++#if defined(COMPILER2) || defined(SHARK) > + CompLevel_highest_tier = CompLevel_full_optimization, // pure C2 and tiered > + #elif defined(COMPILER1) > + CompLevel_highest_tier = CompLevel_simple, // pure C1 > +@@ -754,7 +754,7 @@ > + CompLevel_initial_compile = CompLevel_full_profile // tiered > + #elif defined(COMPILER1) > + CompLevel_initial_compile = CompLevel_simple // pure C1 > +-#elif defined(COMPILER2) > ++#elif defined(COMPILER2) || defined(SHARK) > + CompLevel_initial_compile = CompLevel_full_optimization // pure C2 > + #else > + CompLevel_initial_compile = CompLevel_none > +Index: openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp > +=================================================================== > +--- openjdk.orig/hotspot/src/share/vm/compiler/compileBroker.cpp 2011-04-15 16:05:50.051181001 +0200 > ++++ openjdk/hotspot/src/share/vm/compiler/compileBroker.cpp 2011-04-15 16:08:46.127181000 +0200 > +@@ -768,7 +768,9 @@ > + // Initialize the compilation queue > + void CompileBroker::init_compiler_threads(int c1_compiler_count, int c2_compiler_count) { > + EXCEPTION_MARK; > ++#if !defined(ZERO) && !defined(SHARK) > + assert(c2_compiler_count > 0 || c1_compiler_count > 0, "No compilers?"); > ++#endif // !ZERO && !SHARK > + if (c2_compiler_count > 0) { > + _c2_method_queue = new CompileQueue("C2MethodQueue", MethodCompileQueue_lock); > + } > +@@ -1029,7 +1031,7 @@ > + > + assert(!HAS_PENDING_EXCEPTION, "No exception should be present"); > + // some prerequisites that are compiler specific > +- if (compiler(comp_level)->is_c2()) { > ++ if (compiler(comp_level)->is_c2() || compiler(comp_level)->is_shark()) { > + method->constants()->resolve_string_constants(CHECK_0); > + // Resolve all classes seen in the signature of the method > + // we are compiling. > Index: icedtea6-1.10/ChangeLog > =================================================================== > --- icedtea6-1.10.orig/ChangeLog 2011-04-20 11:47:44.612753002 +0200 > +++ icedtea6-1.10/ChangeLog 2011-04-20 11:53:20.040753002 +0200 > @@ -1,3 +1,11 @@ > +2011-04-20 Xerxes R??nby > + > + PR690: Shark fails to JIT using hs20 > + * Makefile.am: Add WITH_ALT_HSBUILD patch > + * patches/pr690-shark-jit-hs20.patch: > + Backported Shark fixes from OpenJDK bug 7032458. > + * NEWS: Updated. > + > 2011-04-12 Xerxes R??nby > > PR689: Shark fails to find LLVM 2.9 System headers during build > Index: icedtea6-1.10/NEWS > =================================================================== > --- icedtea6-1.10.orig/NEWS 2011-04-20 11:53:31.536753002 +0200 > +++ icedtea6-1.10/NEWS 2011-04-20 11:54:08.648753002 +0200 > @@ -13,6 +13,7 @@ > > * Shark > - PR689: Shark fails to find LLVM 2.9 System headers during build. > + - PR690: Shark fails to JIT using hs20. > > New in release 1.10.1 (2011-04-04): > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Wed Apr 20 15:39:50 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 23:39:50 +0100 Subject: [rfc][icedtea-web]: Tell lruHandler to store after modifying. In-Reply-To: <1601709386.80799.1303304425104.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> References: <44555219.80778.1303304363432.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> <1601709386.80799.1303304425104.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> Message-ID: <20110420223950.GW29985@rivendell.middle-earth.co.uk> On 09:00 Wed 20 Apr , Andrew Su wrote: > Hello, > > It seems like the previous email[1] did not reach some people's inboxes.. Resending as new thread. > > [1]http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013722.html > > Regards, > Andrew Er... what is this? > diff -r 211a5e73d119 netx/net/sourceforge/jnlp/cache/CacheUtil.java > --- a/netx/net/sourceforge/jnlp/cache/CacheUtil.java Mon Apr 18 17:38:31 2011 -0400 > +++ b/netx/net/sourceforge/jnlp/cache/CacheUtil.java Tue Apr 19 17:15:13 2011 -0400 > @@ -307,6 +307,7 @@ > if (cacheFile == null) { // We did not find a copy of it. > cacheFile = makeNewCacheFile(source, version); > } > + lruHandler.store(); > lruHandler.unlock(); > } > return cacheFile; -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Wed Apr 20 15:47:31 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 23:47:31 +0100 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <4DAEC236.2090706@oracle.com> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DADA957.8050004@ubuntu.com> <4DAEA8BC.2030801@oracle.com> <4DAEAC8C.8060901@ubuntu.com> <4DAEC236.2090706@oracle.com> Message-ID: <20110420224731.GZ29985@rivendell.middle-earth.co.uk> On 15:23 Wed 20 Apr , Dmitry Samersoff wrote: > Matthias, > > What is the purpose of this identification? > I would actually like to know this too. In what situations is knowing the distro helpful? > -Dmitry > -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Wed Apr 20 15:49:05 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 23:49:05 +0100 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <20110420184527.GF12304@redhat.com> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> Message-ID: <20110420224905.GA29985@rivendell.middle-earth.co.uk> On 14:45 Wed 20 Apr , Deepak Bhole wrote: > * Omair Majid [2011-04-15 12:28]: > > Updated patch attached. > > > > I'll let Andrew reply to his concerns. I have only one concern (below): > As in me? What concerns? > > Cheers, > Deepak -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Wed Apr 20 15:51:56 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 23:51:56 +0100 Subject: IcedTea7 build failed for 2cd959df7e7a In-Reply-To: <4DAF23B6.1010907@redhat.com> References: <20110420015650.GM29985@rivendell.middle-earth.co.uk> <1303282920.11416.11.camel@springer.wildebeest.org> <20110420142258.GS29985@rivendell.middle-earth.co.uk> <4DAF23B6.1010907@redhat.com> Message-ID: <20110420225155.GB29985@rivendell.middle-earth.co.uk> On 14:19 Wed 20 Apr , Omair Majid wrote: > > Yes, well I haven't tested CACAO in a while. It's not high on my list of priorities. > > Getting the basic build working tends to be more important :-) > > I dug into the cacao errors, and it turns out there are some real > issues. The attached patch updates the cacao patches to apply, but it is > not sufficient. Cacao relies on hpi which was removed in OpenJDK7. Some > of the hpi methods are trivial (Close(int) becomes ::close(int)), but > others (like NativePath(char*)) are non-trivial. I suppose I can copy > over the implementation of those methods from hotspot, but I would > prefer to avoid doing this as an icedtea patch. Perhaps upstream cacao > should be taking care of this. > I was aware there might be a HPI issue. Feel free to apply the patch below (with a ChangeLog). I think the CACAO developers need to sort the bigger issue if they want to retain support in IcedTea7. > Cheers, > Omair > diff -r 8f9c35e54e17 patches/cacao/ignore-tests.patch > --- a/patches/cacao/ignore-tests.patch Tue Apr 19 15:35:23 2011 +0100 > +++ b/patches/cacao/ignore-tests.patch Wed Apr 20 12:22:11 2011 -0400 > @@ -2,7 +2,7 @@ > --- openjdk.orig/jdk/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2010-05-10 15:04:14.000000000 +0100 > +++ openjdk/jdk/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2010-05-10 23:42:41.000000000 +0100 > @@ -37,6 +37,7 @@ > - * @compile ProducerConsumerLoops.java > + * @compile -source 1.5 ProducerConsumerLoops.java > * @run main/timeout=3600 ProducerConsumerLoops > * @summary multiple producers and consumers using blocking queues > + * @ignore cacao test hog, ignore for the sake of buildds > diff -r 8f9c35e54e17 patches/cacao/launcher.patch > --- a/patches/cacao/launcher.patch Tue Apr 19 15:35:23 2011 +0100 > +++ b/patches/cacao/launcher.patch Wed Apr 20 12:22:11 2011 -0400 > @@ -30,7 +30,7 @@ > > args.argc = argc; > @@ -1931,7 +1935,17 @@ > - args.classname = classname; > + args.what = what; > args.ifn = *ifn; > > - rslt = ContinueInNewThread0(JavaMain, threadStackSize, (void*)&args); -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Wed Apr 20 15:55:38 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 18:55:38 -0400 Subject: IcedTea-Web 1.1 branching on _Friday_ In-Reply-To: <20110413160025.GD28506@redhat.com> References: <20110411201208.GA6019@redhat.com> <20110413155657.GC28506@redhat.com> <20110413160025.GD28506@redhat.com> Message-ID: <20110420225537.GS12304@redhat.com> Top-posting because this is not a query reply.. Just an update on what is happening. 1.1 branching was stalled to allow caching related changes to go in. Cache manipulation support for itweb-settings is one of the major features for 1.1 so branching was pushed ahead till it went it. All related patches are now in. There are a handful of patches waiting review/approval, but they are fairly small I don't see any reason to hold off branching on them -- we will just backport them. Please let me know if you need me to halt branching for any reason. If not, I will branch for 1.1 tomorrow (Thursday, April 21st). Since branching will be pushed ahead, release will be pushed ahead accordingly. New proposed date is Monday, May 2nd 2011. I've updated the wiki accordingly. Cheers, Deepak * Deepak Bhole [2011-04-13 12:01]: > > Annnddd of course, I forgot to update $subject ... fixed > > * Deepak Bhole [2011-04-13 11:57]: > > Hi, > > > > I sent this email on Monday but it seems that the original > > email didn't end up in inboxes even though it is on the > > site :/ If you did get the email, please note the updated > > schedule. > > > > ... > > > > Significant development has been done on IcedTea-Web since 1.0 was > > branched and I think it is time to start thinking of 1.1. I was > > thinking of branching at end of Friday (Apr. 15th) and then a > > release on the 28th after making sure things are stable. > > > > Once branched, no more features will be allowed in. > > > > Please let me know if you have any concerns about the above dates. > > > > Cheers, > > Deepak From ahughes at redhat.com Wed Apr 20 15:59:48 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 20 Apr 2011 23:59:48 +0100 Subject: IcedTea-Web 1.1 branching on _Friday_ In-Reply-To: <20110420225537.GS12304@redhat.com> References: <20110411201208.GA6019@redhat.com> <20110413155657.GC28506@redhat.com> <20110413160025.GD28506@redhat.com> <20110420225537.GS12304@redhat.com> Message-ID: <20110420225948.GD29985@rivendell.middle-earth.co.uk> On 18:55 Wed 20 Apr , Deepak Bhole wrote: > > Top-posting because this is not a query reply.. > > Just an update on what is happening. 1.1 branching was stalled to > allow caching related changes to go in. Cache manipulation support for > itweb-settings is one of the major features for 1.1 so branching was > pushed ahead till it went it. > > All related patches are now in. There are a handful of patches waiting > review/approval, but they are fairly small I don't see any reason to > hold off branching on them -- we will just backport them. > > Please let me know if you need me to halt branching for any reason. If > not, I will branch for 1.1 tomorrow (Thursday, April 21st). > > Since branching will be pushed ahead, release will be pushed ahead > accordingly. New proposed date is Monday, May 2nd 2011. I've updated > the wiki accordingly. > Can we make it Tuesday or Wednesday for the release? Monday the 2nd is a bank holiday in the UK. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Wed Apr 20 16:00:56 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 19:00:56 -0400 Subject: [icedtea-web] RFC: find jars based on Class-Path entry in manifest In-Reply-To: <20110420224905.GA29985@rivendell.middle-earth.co.uk> References: <4DA75A72.30008@redhat.com> <20110414223819.GM7262@rivendell.middle-earth.co.uk> <4DA77E94.1000901@redhat.com> <20110415005024.GR7262@rivendell.middle-earth.co.uk> <4DA871EB.2060907@redhat.com> <20110420184527.GF12304@redhat.com> <20110420224905.GA29985@rivendell.middle-earth.co.uk> Message-ID: <20110420230056.GU12304@redhat.com> * Dr Andrew John Hughes [2011-04-20 18:49]: > On 14:45 Wed 20 Apr , Deepak Bhole wrote: > > * Omair Majid [2011-04-15 12:28]: > > > Updated patch attached. > > > > > > > I'll let Andrew reply to his concerns. I have only one concern (below): > > > > As in me? What concerns? > Hmm, I guess just if you are okay with the comments added for getClassPathsFromManifest: From http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013638.html "Do the comments in getClassPathsFromManifest help?" Cheers, Deepak > > > > Cheers, > > Deepak > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dbhole at redhat.com Wed Apr 20 16:08:16 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 19:08:16 -0400 Subject: IcedTea-Web 1.1 branching on _Friday_ In-Reply-To: <20110420225948.GD29985@rivendell.middle-earth.co.uk> References: <20110411201208.GA6019@redhat.com> <20110413155657.GC28506@redhat.com> <20110413160025.GD28506@redhat.com> <20110420225537.GS12304@redhat.com> <20110420225948.GD29985@rivendell.middle-earth.co.uk> Message-ID: <20110420230816.GV12304@redhat.com> * Dr Andrew John Hughes [2011-04-20 18:59]: > On 18:55 Wed 20 Apr , Deepak Bhole wrote: > > > > Top-posting because this is not a query reply.. > > > > Just an update on what is happening. 1.1 branching was stalled to > > allow caching related changes to go in. Cache manipulation support for > > itweb-settings is one of the major features for 1.1 so branching was > > pushed ahead till it went it. > > > > All related patches are now in. There are a handful of patches waiting > > review/approval, but they are fairly small I don't see any reason to > > hold off branching on them -- we will just backport them. > > > > Please let me know if you need me to halt branching for any reason. If > > not, I will branch for 1.1 tomorrow (Thursday, April 21st). > > > > Since branching will be pushed ahead, release will be pushed ahead > > accordingly. New proposed date is Monday, May 2nd 2011. I've updated > > the wiki accordingly. > > > > Can we make it Tuesday or Wednesday for the release? Monday the 2nd > is a bank holiday in the UK. I will be away at Red Hat summit from the 3rd to the 5th. How about the 6th? I can do it first thing in the morning ... Cheers, Deepak > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From xerxes at zafena.se Wed Apr 20 16:18:57 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 21 Apr 2011 01:18:57 +0200 Subject: RFC: icedtea6-1.9: PR632: 6878713.patch breaks shark zero build Message-ID: <4DAF69E1.8000704@zafena.se> Hi team Here are the missing review to add PR632 to the icedtea6-1.9 release branch. Ok to push? Cheers Xerxes -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-1.9-PR632.patch Type: text/x-patch Size: 2948 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110421/1628dbe0/icedtea6-1.9-PR632.patch From dbhole at redhat.com Wed Apr 20 16:40:38 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Wed, 20 Apr 2011 19:40:38 -0400 Subject: IcedTea-Web 1.1 branching on _Friday_ In-Reply-To: <20110420230816.GV12304@redhat.com> References: <20110411201208.GA6019@redhat.com> <20110413155657.GC28506@redhat.com> <20110413160025.GD28506@redhat.com> <20110420225537.GS12304@redhat.com> <20110420225948.GD29985@rivendell.middle-earth.co.uk> <20110420230816.GV12304@redhat.com> Message-ID: <20110420234038.GW12304@redhat.com> * Deepak Bhole [2011-04-20 19:09]: > * Dr Andrew John Hughes [2011-04-20 18:59]: > > On 18:55 Wed 20 Apr , Deepak Bhole wrote: > > > > > > Top-posting because this is not a query reply.. > > > > > > Just an update on what is happening. 1.1 branching was stalled to > > > allow caching related changes to go in. Cache manipulation support for > > > itweb-settings is one of the major features for 1.1 so branching was > > > pushed ahead till it went it. > > > > > > All related patches are now in. There are a handful of patches waiting > > > review/approval, but they are fairly small I don't see any reason to > > > hold off branching on them -- we will just backport them. > > > > > > Please let me know if you need me to halt branching for any reason. If > > > not, I will branch for 1.1 tomorrow (Thursday, April 21st). > > > > > > Since branching will be pushed ahead, release will be pushed ahead > > > accordingly. New proposed date is Monday, May 2nd 2011. I've updated > > > the wiki accordingly. > > > > > > > Can we make it Tuesday or Wednesday for the release? Monday the 2nd > > is a bank holiday in the UK. > > I will be away at Red Hat summit from the 3rd to the 5th. How about the > 6th? I can do it first thing in the morning ... > Just an FYI, release date will now be May 6th 2011 (spoke with Andrew on IRC). Wiki updated. Cheers, Deepak > Cheers, > Deepak > > > -- > > Andrew :) > > > > Free Java Software Engineer > > Red Hat, Inc. (http://www.redhat.com) > > > > Support Free Java! > > Contribute to GNU Classpath and IcedTea > > http://www.gnu.org/software/classpath > > http://icedtea.classpath.org > > PGP Key: F5862A37 (https://keys.indymedia.org/) > > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Wed Apr 20 17:06:26 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 21 Apr 2011 01:06:26 +0100 Subject: RFC: icedtea6-1.9: PR632: 6878713.patch breaks shark zero build In-Reply-To: <4DAF69E1.8000704@zafena.se> References: <4DAF69E1.8000704@zafena.se> Message-ID: <20110421000626.GE29985@rivendell.middle-earth.co.uk> On 01:18 Thu 21 Apr , Xerxes R?nby wrote: > Hi team > > Here are the missing review to add PR632 to the icedtea6-1.9 release branch. > > Ok to push? > > Cheers > Xerxes Does this apply fine with both HotSpots in 1.9? I take it the other branches were done and this got missed? > > # HG changeset patch > # User Mark Wielaard > # Date 1297891430 -3600 > # Node ID 3f247fe29393767e0e6692cdc7fb6551a36a5480 > # Parent 58276c6748af3665ffc8247071de1faebdaf6c05 > PR632: 6878713.patch breaks shark zero build > > 2011-02-16 Xerxes Ranby > Mark Wielaard > > PR632: 6878713.patch breaks shark zero build > * patches/icedtea-stdc-limit-macros.patch > (openjdk/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp): > Only define __STDC_LIMIT_MACROS if undefined. > * Makefile.am (ICEDTEA_PATCHES): Add new patch. > * NEWS: Updated. > > Index: icedtea6-1.9/Makefile.am > =================================================================== > --- icedtea6-1.9.orig/Makefile.am 2011-04-21 00:04:59.000000000 +0200 > +++ icedtea6-1.9/Makefile.am 2011-04-21 00:39:14.528180000 +0200 > @@ -230,6 +230,7 @@ > > ICEDTEA_PATCHES = \ > $(SECURITY_PATCHES) \ > + patches/icedtea-stdc-limit-macros.patch \ > patches/icedtea-notice-safepoints.patch \ > patches/icedtea-parisc-opt.patch \ > patches/icedtea-lucene-crash.patch \ > Index: icedtea6-1.9/NEWS > =================================================================== > --- icedtea6-1.9.orig/NEWS 2011-04-21 00:04:59.000000000 +0200 > +++ icedtea6-1.9/NEWS 2011-04-21 00:37:23.564180001 +0200 > @@ -18,6 +18,7 @@ > * Plugin > - PR542: Plugin fails with NPE on http://www.openprocessing.org/visuals/iframe.php?visualID=2615 > * Shark > + - PR632: patches/security/20110215/6878713.patch breaks shark zero build > - PR689: Shark fails to find LLVM 2.9 System headers during build > > New in release 1.9.7 (2011-02-15): > Index: icedtea6-1.9/patches/icedtea-stdc-limit-macros.patch > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ icedtea6-1.9/patches/icedtea-stdc-limit-macros.patch 2011-04-21 00:34:18.900180000 +0200 > @@ -0,0 +1,12 @@ > +--- openjdk/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp > ++++ openjdk/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp > +@@ -72,7 +72,9 @@ > + # endif > + > + #ifdef LINUX > ++#ifndef __STDC_LIMIT_MACROS > + #define __STDC_LIMIT_MACROS > ++#endif > + #include > + #include > + #include > Index: icedtea6-1.9/ChangeLog > =================================================================== > --- icedtea6-1.9.orig/ChangeLog 2011-04-21 00:04:59.000000000 +0200 > +++ icedtea6-1.9/ChangeLog 2011-04-21 00:48:24.528180002 +0200 > @@ -1,3 +1,13 @@ > +2011-04-21 Xerxes R??nby > + Mark Wielaard > + > + PR632: 6878713.patch breaks shark zero build > + * patches/icedtea-stdc-limit-macros.patch > + (openjdk/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp): > + Only define __STDC_LIMIT_MACROS if undefined. > + * Makefile.am (ICEDTEA_PATCHES): Add new patch. > + * NEWS: Updated. > + > 2011-04-15 Pavel Tisnovsky > > * Makefile.am: Add new patch. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From xerxes at zafena.se Wed Apr 20 17:45:13 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 21 Apr 2011 02:45:13 +0200 Subject: RFC: icedtea6-1.9: PR632: 6878713.patch breaks shark zero build In-Reply-To: <20110421000626.GE29985@rivendell.middle-earth.co.uk> References: <4DAF69E1.8000704@zafena.se> <20110421000626.GE29985@rivendell.middle-earth.co.uk> Message-ID: <4DAF7E19.10505@zafena.se> On 2011-04-21 02:06, Dr Andrew John Hughes wrote: > On 01:18 Thu 21 Apr , Xerxes R?nby wrote: >> Hi team >> >> Here are the missing review to add PR632 to the icedtea6-1.9 release branch. >> >> Ok to push? >> > > Does this apply fine with both HotSpots in 1.9? Applies fine using (default)hs17 and hs19 in 1.9. > > I take it the other branches were done and this got missed? Yes this got missed. 1.8, 1.10 and trunk have all-ready been patched. From xerxes at zafena.se Wed Apr 20 17:56:51 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Thu, 21 Apr 2011 02:56:51 +0200 Subject: RFC: PR690: Shark fails to JIT using hs20 In-Reply-To: <20110420223111.GT29985@rivendell.middle-earth.co.uk> References: <4DAEB54F.2060806@zafena.se> <20110420223111.GT29985@rivendell.middle-earth.co.uk> Message-ID: <4DAF80D3.2030501@zafena.se> On 2011-04-21 00:31, Dr Andrew John Hughes wrote: > On 12:28 Wed 20 Apr , Xerxes R?nby wrote: >> Hi the attached patches updates icedtea6-1.10 and icedtea6 trunk to make the Shark JIT work when using HotSpot 20 and later: >> I have tested these patches using the following three configurations: >> >> ../icedtea6-1.10/configure --enable-shark --disable-bootstrap --disable-docs --with-hotspot-build >> >> ../icedtea6/configure --enable-shark --disable-docs --disable-bootstrap >> ../icedtea6/configure --enable-shark --disable-bootstrap --disable-docs --with-hotspot-build >> >> >> Ok to push to IcedTea6-1.10 release branch? >> >> Ok to push to IcedTea6 trunk? >> > > What part of 7032458 is being used here? I'm concerned that neither the NEWS item > nor the patch file mention 7032458. Are there parts of 7032458 that don't apply? There are parts of 7032458 that do not apply. a zero fix and some non-hs20 parts. I have posted this patch upstream for review in hope to get a new bug id that only track this hs20 regression. > > The patch claims to be for hs20 but you seem to be applying it unconditionally > (and thus for hs19 too). The patch for icedtea6 trunk are applying it unconditionally since it are already using hs20 by default. Index: icedtea6/Makefile.am =================================================================== --- icedtea6.orig/Makefile.am 2011-04-20 11:39:13.640753000 +0200 +++ icedtea6/Makefile.am 2011-04-20 11:39:55.248753002 +0200 @@ -336,7 +336,8 @@ patches/revert-6885123.patch \ patches/hotspot/$(HSBUILD)/7032388-work_without_cmov_instruction.patch \ patches/openjdk/7031385-gcc-register-allocation-fix.patch \ - patches/shark-llvm-2.9.patch + patches/shark-llvm-2.9.patch \ + patches/pr690-shark-jit-hs20.patch if WITH_ALT_HSBUILD ICEDTEA_PATCHES += \ The patch for icedtea6-1.10 are conditionally for WITH_ALT_HSBUILD to only apply for hs20. >> Index: icedtea6-1.10/Makefile.am >> =================================================================== >> --- icedtea6-1.10.orig/Makefile.am 2011-04-20 11:42:37.816753001 +0200 >> +++ icedtea6-1.10/Makefile.am 2011-04-20 11:44:13.344753002 +0200 >> @@ -335,6 +335,7 @@ >> if WITH_ALT_HSBUILD >> ICEDTEA_PATCHES += \ >> patches/pr639-broken_shark_build.patch \ >> + patches/pr690-shark-jit-hs20.patch \ >> patches/hotspot/$(HSBUILD)/powerpc-stacksize.patch >> else >> ICEDTEA_PATCHES += \ From bugzilla-daemon at icedtea.classpath.org Wed Apr 20 18:17:22 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 01:17:22 +0000 Subject: [Bug 697] New: Shark fails to build docs using hs19 Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=697 Summary: Shark fails to build docs using hs19 Product: IcedTea Version: 6-hg Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Shark AssignedTo: unassigned at icedtea.classpath.org ReportedBy: xerxes at zafena.se Testcase: ../icedtea6-1.9/configure --enable-shark --with-hotspot-build fails during compilation of docs ... # org.xml.sax # org.xml.sax.ext # org.xml.sax.helpers /home/xranby/icedtea6-1.9-shark-hs19/bootstrap/jdk1.6.0/bin/java -client -Xmx512m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/home/xranby/icedtea6-1.9-shark-hs19/openjdk.build/langtools/dist/bootstrap/lib/javadoc.jar:/home/xranby/icedtea6-1.9-shark-hs19/openjdk.build/langtools/dist/bootstrap/lib/javac.jar:/home/xranby/icedtea6-1.9-shark-hs19/openjdk.build/langtools/dist/bootstrap/lib/doclets.jar" -jar /home/xranby/icedtea6-1.9-shark-hs19/openjdk.build/langtools/dist/bootstrap/lib/javadoc.jar -d /home/xranby/icedtea6-1.9-shark-hs19/openjdk.build/docs/api \ @/home/xranby/icedtea6-1.9-shark-hs19/openjdk.build/tmp/docs/doctmp/coredocs.options @/home/xranby/icedtea6-1.9-shark-hs19/openjdk.build/tmp/docs/doctmp/coredocs.packages # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (os_linux_zero.cpp:236), pid=23677, tid=1097759600 # fatal error: caught unhandled signal 11 # # JRE version: 6.0_20-b20 # Java VM: OpenJDK Shark VM (19.0-b09 mixed mode linux-i386 ) # Derivative: IcedTea6 1.9.8pre+r2f549e3a4720 # Distribution: Built on Ubuntu Natty (development branch) (Thu Apr 21 01:06:41 CEST 2011) # An error report file with more information is saved as: # /home/xranby/icedtea6-1.9-shark-hs19/openjdk/jdk/make/docs/hs_err_pid23677.log # # If you would like to submit a bug report, please include # instructions how to reproduce the bug and visit: # http://icedtea.classpath.org/bugzilla # Aborted (core dumped) A full bootstrap build work when using Shark in combination with hs17. xranby at hp:~/icedtea6-1.9-shark$ ../icedtea6-1.9/configure --enable-shark make Summary: As to date 2011-04-21 icedtea6-1.9 release branch contains the only stable Shark release when built against (default)hs17. Shark are broken when using hs19 and later. Please run full bootstrap builds when testing Shark since the generation of docs are a good test for the reflection API implementations in Shark! -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 02:57:51 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 09:57:51 +0000 Subject: [Bug 697] Shark fails to build docs using hs19 In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=697 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE --- Comment #1 from Xerxes R?nby 2011-04-21 09:57:50 --- *** This bug has been marked as a duplicate of bug 559 *** -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 02:57:51 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 09:57:51 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerxes at zafena.se --- Comment #3 from Xerxes R?nby 2011-04-21 09:57:50 --- *** Bug 697 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 02:58:33 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 09:58:33 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 --- Comment #4 from Xerxes R?nby 2011-04-21 09:58:33 --- gdb backtrace Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7fe4b70 (LWP 14764)] 0x01c6743f in java.lang.Class_3A__3A_getName () (gdb) bt #0 0x01c6743f in java.lang.Class_3A__3A_getName () #1 0x01c7ebec in com.sun.tools.doclets.internal.toolkit.util.Util_3A__3A_isDeprecated () #2 0x003d5e3f in invoke (recurse=0, __the_thread__=0x80636e0) at /media/2d0c92b2-31e4-49ad-b101-e1584b930ca6/build/icedtea6-1.9-shark-hs19/openjdk-ecj/hotspot/src/cpu/zero/vm/entry_zero.hpp:56 #3 invoke_method (recurse=0, __the_thread__=0x80636e0) at /media/2d0c92b2-31e4-49ad-b101-e1584b930ca6/build/icedtea6-1.9-shark-hs19/openjdk-ecj/hotspot/src/cpu/zero/vm/interpreter_zero.hpp:28 #4 CppInterpreter::main_loop (recurse=0, __the_thread__=0x80636e0) at /media/2d0c92b2-31e4-49ad-b101-e1584b930ca6/build/icedtea6-1.9-shark-hs19/openjdk-ecj/hotspot/src/cpu/zero/vm/cppInterpreter_zero.cpp:95 #5 0x003d6b8e in CppInterpreter::normal_entry (method=0xac585230, -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 05:07:06 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 12:07:06 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 --- Comment #5 from Xerxes R?nby 2011-04-21 12:07:06 --- Created an attachment (id=520) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=520) hs19 disassembly .s and .ll of frame 1 com.sun.tools.doclets.internal.toolkit.util.Util_3A__3A_isDeprecated -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 05:09:50 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 12:09:50 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 --- Comment #6 from Xerxes R?nby 2011-04-21 12:09:50 --- Created an attachment (id=521) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=521) hs17-diff-hs19-com.sun.tools.doclets.internal.toolkit.util.Util::isDeprecated.ll the Shark generated IR of com.sun.tools.doclets.internal.toolkit.util.Util::isDeprecated.ll differs between hs17 and hs19 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 05:11:30 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 12:11:30 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 --- Comment #7 from Xerxes R?nby 2011-04-21 12:11:29 --- Created an attachment (id=522) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=522) hs17-diff-hs19-java.lang.Class::getName.ll The Shark generated LLVM IR of java.lang.Class::getName.ll do not significantly differ between hs17 and hs19. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 05:12:48 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 12:12:48 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 --- Comment #8 from Xerxes R?nby 2011-04-21 12:12:47 --- Created an attachment (id=523) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=523) hs19-com.sun.tools.doclets.internal.toolkit.util.Util::isDeprecated.ll -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 05:13:10 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 12:13:10 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 --- Comment #9 from Xerxes R?nby 2011-04-21 12:13:10 --- Created an attachment (id=524) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=524) hs19-java.lang.Class::getName.ll -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 05:15:30 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 12:15:30 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 --- Comment #10 from Xerxes R?nby 2011-04-21 12:15:30 --- Created an attachment (id=525) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=525) hs17-hs19 diff between the hotspot share/vm/shark directory diff -Naur icedtea6-1.9-shark/openjdk/hotspot/src/share/vm/shark icedtea6-1.9-shark-hs19/openjdk/hotspot/src/share/vm/shark -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Thu Apr 21 05:26:46 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Thu, 21 Apr 2011 12:26:46 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gbenson at redhat.com --- Comment #11 from Xerxes R?nby 2011-04-21 12:26:45 --- (14.20.06) gbenson: the shark changes don't look problematic (14.20.19) gbenson: and the getclass.ll hasn't changed except for addresses (14.20.37) gbenson: I think something outside of shark has changed, and shark needs to mirror it (14.20.50) gbenson: xranby: have you tried a build with assertions etc? (14.21.31) xranby: gbenson: no i still have not tested everything :/ (14.21.39) gbenson: that might show something up (14.21.46) gbenson: an assertion failure perhaps -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From asu at redhat.com Thu Apr 21 06:07:47 2011 From: asu at redhat.com (Andrew Su) Date: Thu, 21 Apr 2011 09:07:47 -0400 (EDT) Subject: [rfc][icedtea-web]: Tell lruHandler to store after modifying. In-Reply-To: <20110420223950.GW29985@rivendell.middle-earth.co.uk> Message-ID: <336780548.104442.1303391267273.JavaMail.root@zmail01.collab.prod.int.phx2.redhat.com> ----- Original Message ----- > From: "Dr Andrew John Hughes" > To: "Andrew Su" > Cc: "IcedTea" > Sent: Wednesday, April 20, 2011 6:39:50 PM > Subject: Re: [rfc][icedtea-web]: Tell lruHandler to store after modifying. > On 09:00 Wed 20 Apr , Andrew Su wrote: > > Hello, > > > > It seems like the previous email[1] did not reach some people's > > inboxes.. Resending as new thread. > > > > [1]http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013722.html > > > > Regards, > > Andrew > > Er... what is this? Hm? What do you mean? -- When an item in exist in our recently_used file, and we grab it from getCacheFileIfExist(). It updates the time last accessed locally, but never actually writes it back to file. Cheers, Andrew --snip-- From omajid at redhat.com Thu Apr 21 07:57:53 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 21 Apr 2011 10:57:53 -0400 Subject: [icedtea-web] RFC: Use non-blocking NPN_GetURLNotify In-Reply-To: <20110420200853.GP12304@redhat.com> References: <20110420193643.GM12304@redhat.com> <20110420200853.GP12304@redhat.com> Message-ID: <4DB045F1.1070901@redhat.com> On 04/20/2011 04:08 PM, Deepak Bhole wrote: > This one didn't appear in my inbox :/ re-sending... > > * Deepak Bhole [2011-04-20 15:36]: >> Hi, >> >> Attached patch mitigates the issue mentioned here: >> http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013706.html >> >> This patch uses a non-blocking function to get the URL. We discard the >> eventual notification, but that is no different that what we do right now >> (we just print it currently and ignore it). For that matter, there isn't >> really much we _can_ do in case of load failure anyway.. >> >> ChangeLog: >> 2011-04-20 Deepak Bhole >> >> * plugin/icedteanp/IcedTeaNPPlugin.cc (consume_message): Use >> NPN_GetURLNotify (non-blocking) instead of NPN_GetURL (blocking) so that >> the plugin is free to process additional requests. >> >> Okay for HEAD and 1.0? Looks good to me. Cheers, Omair From dbhole at redhat.com Thu Apr 21 08:04:20 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 21 Apr 2011 11:04:20 -0400 Subject: [icedtea-web] RFC: Use non-blocking NPN_GetURLNotify In-Reply-To: <4DB045F1.1070901@redhat.com> References: <20110420193643.GM12304@redhat.com> <20110420200853.GP12304@redhat.com> <4DB045F1.1070901@redhat.com> Message-ID: <20110421150417.GA7494@redhat.com> * Omair Majid [2011-04-21 10:57]: > On 04/20/2011 04:08 PM, Deepak Bhole wrote: > >This one didn't appear in my inbox :/ re-sending... > > > >* Deepak Bhole [2011-04-20 15:36]: > >>Hi, > >> > >>Attached patch mitigates the issue mentioned here: > >>http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-April/013706.html > >> > >>This patch uses a non-blocking function to get the URL. We discard the > >>eventual notification, but that is no different that what we do right now > >>(we just print it currently and ignore it). For that matter, there isn't > >>really much we _can_ do in case of load failure anyway.. > >> > >>ChangeLog: > >>2011-04-20 Deepak Bhole > >> > >> * plugin/icedteanp/IcedTeaNPPlugin.cc (consume_message): Use > >> NPN_GetURLNotify (non-blocking) instead of NPN_GetURL (blocking) so that > >> the plugin is free to process additional requests. > >> > >>Okay for HEAD and 1.0? > > Looks good to me. > Thanks! Cheers, Deepak > Cheers, > Omair From dbhole at icedtea.classpath.org Thu Apr 21 08:08:19 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Thu, 21 Apr 2011 15:08:19 +0000 Subject: /hg/icedtea-web: Use NPN_GetURLNotify (non-blocking) instead of ... Message-ID: changeset b60550517945 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=b60550517945 author: Deepak Bhole date: Thu Apr 21 11:08:02 2011 -0400 Use NPN_GetURLNotify (non-blocking) instead of NPN_GetURL (blocking) Fixed spacing issues in previous ChangeLog entry diffstat: ChangeLog | 15 +++++++++++---- plugin/icedteanp/IcedTeaNPPlugin.cc | 2 +- 2 files changed, 12 insertions(+), 5 deletions(-) diffs (36 lines): diff -r a50cd6a66ae6 -r b60550517945 ChangeLog --- a/ChangeLog Wed Apr 20 16:58:29 2011 -0400 +++ b/ChangeLog Thu Apr 21 11:08:02 2011 -0400 @@ -1,9 +1,16 @@ +2011-04-21 Deepak Bhole + + * plugin/icedteanp/IcedTeaNPPlugin.cc (consume_message): Use + NPN_GetURLNotify (non-blocking) instead of NPN_GetURL (blocking) so that + the plugin is free to process additional requests. + * ChangeLog: Fixed spacing issues in previous entry. + 2011-04-20 Andrew Su - * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: - (createButtonPanel): Changed to update the recently_used file to - reflect the deletion. Added method updateRecentlyUsed to anonymous - ActionListener class which will do the actual updating. + * netx/net/sourceforge/jnlp/controlpanel/CachePane.java: + (createButtonPanel): Changed to update the recently_used file to + reflect the deletion. Added method updateRecentlyUsed to anonymous + ActionListener class which will do the actual updating. 2011-04-20 Omair Majid diff -r a50cd6a66ae6 -r b60550517945 plugin/icedteanp/IcedTeaNPPlugin.cc --- a/plugin/icedteanp/IcedTeaNPPlugin.cc Wed Apr 20 16:58:29 2011 -0400 +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc Thu Apr 21 11:08:02 2011 -0400 @@ -1179,7 +1179,7 @@ PLUGIN_DEBUG ("plugin_in_pipe_callback: URL target %s\n", parts[4]); NPError np_error = - (*browser_functions.geturl) (data->owner, decoded_url, parts[4]); + (*browser_functions.geturlnotify) (data->owner, decoded_url, parts[4], NULL); if (np_error != NPERR_NO_ERROR) From dbhole at icedtea.classpath.org Thu Apr 21 08:08:11 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Thu, 21 Apr 2011 15:08:11 +0000 Subject: /hg/release/icedtea-web-1.0: Use NPN_GetURLNotify (non-blocking)... Message-ID: changeset bb091ba157f2 in /hg/release/icedtea-web-1.0 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.0?cmd=changeset;node=bb091ba157f2 author: Deepak Bhole date: Thu Apr 21 11:06:03 2011 -0400 Use NPN_GetURLNotify (non-blocking) instead of NPN_GetURL (blocking). diffstat: ChangeLog | 6 ++++++ plugin/icedteanp/IcedTeaNPPlugin.cc | 2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diffs (25 lines): diff -r 2b7512af4dcc -r bb091ba157f2 ChangeLog --- a/ChangeLog Mon Apr 18 13:16:39 2011 -0400 +++ b/ChangeLog Thu Apr 21 11:06:03 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-21 Deepak Bhole + + * plugin/icedteanp/IcedTeaNPPlugin.cc (consume_message): Use + NPN_GetURLNotify (non-blocking) instead of NPN_GetURL (blocking) so that + the plugin is free to process additional requests. + 2011-04-18 Deepak Bhole * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java diff -r 2b7512af4dcc -r bb091ba157f2 plugin/icedteanp/IcedTeaNPPlugin.cc --- a/plugin/icedteanp/IcedTeaNPPlugin.cc Mon Apr 18 13:16:39 2011 -0400 +++ b/plugin/icedteanp/IcedTeaNPPlugin.cc Thu Apr 21 11:06:03 2011 -0400 @@ -1177,7 +1177,7 @@ PLUGIN_DEBUG ("plugin_in_pipe_callback: URL target %s\n", parts[4]); NPError np_error = - (*browser_functions.geturl) (data->owner, decoded_url, parts[4]); + (*browser_functions.geturlnotify) (data->owner, decoded_url, parts[4], NULL); if (np_error != NPERR_NO_ERROR) From dbhole at icedtea.classpath.org Thu Apr 21 08:18:13 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Thu, 21 Apr 2011 15:18:13 +0000 Subject: /hg/icedtea-web: Added tag icedtea-web-1.1-branchpoint for chang... Message-ID: changeset b3b9e39c9c07 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=b3b9e39c9c07 author: Deepak Bhole date: Thu Apr 21 11:18:04 2011 -0400 Added tag icedtea-web-1.1-branchpoint for changeset b60550517945 diffstat: .hgtags | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diffs (6 lines): diff -r b60550517945 -r b3b9e39c9c07 .hgtags --- a/.hgtags Thu Apr 21 11:08:02 2011 -0400 +++ b/.hgtags Thu Apr 21 11:18:04 2011 -0400 @@ -1,1 +1,2 @@ 692d7e5b31039156aff1600fd7f5034fead2f258 icedtea-web-1.0-branchpoint +b605505179459c9f2119e4dfde999fc6300e4c87 icedtea-web-1.1-branchpoint From dbhole at icedtea.classpath.org Thu Apr 21 08:19:33 2011 From: dbhole at icedtea.classpath.org (dbhole at icedtea.classpath.org) Date: Thu, 21 Apr 2011 15:19:33 +0000 Subject: /hg/icedtea-web: Bumped version in configure.ac to 1.2pre Message-ID: changeset a348c6cd5915 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=a348c6cd5915 author: Deepak Bhole date: Thu Apr 21 11:19:28 2011 -0400 Bumped version in configure.ac to 1.2pre diffstat: ChangeLog | 4 ++++ configure.ac | 2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diffs (20 lines): diff -r b3b9e39c9c07 -r a348c6cd5915 ChangeLog --- a/ChangeLog Thu Apr 21 11:18:04 2011 -0400 +++ b/ChangeLog Thu Apr 21 11:19:28 2011 -0400 @@ -1,3 +1,7 @@ +2011-04-21 Deepak Bhole + + * configure.ac: Bumped version to 1.2pre + 2011-04-21 Deepak Bhole * plugin/icedteanp/IcedTeaNPPlugin.cc (consume_message): Use diff -r b3b9e39c9c07 -r a348c6cd5915 configure.ac --- a/configure.ac Thu Apr 21 11:18:04 2011 -0400 +++ b/configure.ac Thu Apr 21 11:19:28 2011 -0400 @@ -1,4 +1,4 @@ -AC_INIT([icedtea-web],[1.1pre],[distro-pkg-dev at openjdk.java.net], [icedtea-web], [http://icedtea.classpath.org/wiki/IcedTea-Web]) +AC_INIT([icedtea-web],[1.2pre],[distro-pkg-dev at openjdk.java.net], [icedtea-web], [http://icedtea.classpath.org/wiki/IcedTea-Web]) AM_INIT_AUTOMAKE([1.9 tar-pax foreign]) AC_CONFIG_FILES([Makefile netx.manifest]) From dbhole at redhat.com Thu Apr 21 08:24:20 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 21 Apr 2011 11:24:20 -0400 Subject: IcedTea-Web 1.1 branched Message-ID: <20110421152419.GB7494@redhat.com> Hi, IcedTea-Web 1.1 has been branched! Please give it a try and let us know if you find any issues: http://icedtea.classpath.org/hg/release/icedtea-web-1.1/ The 1.1 release is scheduled for Friday, May 6th 2011. The next release will most likely be 2.0, but I have set it to 1.2 for now until that decision is concrete. Thanks, Deepak From dbhole at redhat.com Thu Apr 21 08:31:35 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 21 Apr 2011 11:31:35 -0400 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <4DADD105.30103@icyb.net.ua> References: <4DADADC8.7010404@icyb.net.ua> <4DADCF06.8080803@smedbergs.us> <4DADD105.30103@icyb.net.ua> Message-ID: <20110421153134.GC7494@redhat.com> * Andriy Gapon [2011-04-19 14:16]: > on 19/04/2011 21:05 Benjamin Smedberg said the following: > > It sounds like this could possibly be related to the plugin process implementation > > in Firefox 4 > > I am not if this is really so... > IcedTea plugin itself spawns a JVM process to handle applet byte code. I am not > sure if that has any relation to what Firefox does for/on/about plugins. > Hi, I have modified the plugin to use NPN_GetURLNotify instead of NPN_GetURL. The former is non-blocking, and thus allows the plugin to continue to service requests. This should solve the problem in the interim. Andriy, can you please give it a try? Instructions to get, build and use the latest icedtea-web are here: http://icedtea.classpath.org/wiki/?title=IcedTea-Web#Getting_IcedTea-Web Thanks, Deepak > -- > Andriy Gapon From omajid at redhat.com Thu Apr 21 08:47:45 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 21 Apr 2011 11:47:45 -0400 Subject: RFC: drop bytebuffer-compact patch from icedtea6 Message-ID: <4DB051A1.5030005@redhat.com> Hi, The bytebuffer-compact patch in icedtea6 was meant to address PR60. This bug was fixed independently in openjdk6 as 6593946: (bf) X-Buffer.compact() does not discard mark as specified. Since the fix was applied upstream, the icedtea patch was modified so it did not conflict with upstream. The openjdk6 fix introduces a new method discardMark() in java.nio.Buffer, which is simply "mark = -1". The icedtea6 patch (as it stands currently) introduces a new method clearMark() (in addition to the discardMark() which is used elsewhere in the jdk) which does the exact same thing, and then replaces all uses of "mark = -1" in java.nio.Buffer class with clearMark(). IMHO, this patch is useless and should be dropped. The IcedTea7 version of the patch can also be dropped, but at least that just replaces "mark = -1" with discardMark() and does not introduce any new methods. Any thoughts or concerns? ChangeLog 2011-04-21 Omair Majid * Makefile.am (ICEDTEA_PATCHES): Drop bytebuffer-compact.patch * patches/bytebuffer-compact.patch: Remove useless patch. Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-remove-bytebuffer-patch.patch Type: text/x-patch Size: 2147 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110421/5dd308f1/icedtea6-remove-bytebuffer-patch.patch From omajid at redhat.com Thu Apr 21 09:13:42 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 21 Apr 2011 12:13:42 -0400 Subject: RFC: drop bytebuffer-compact patch from icedtea6 In-Reply-To: <4DB051A1.5030005@redhat.com> References: <4DB051A1.5030005@redhat.com> Message-ID: <4DB057B6.9080800@redhat.com> On 04/21/2011 11:47 AM, Omair Majid wrote: > Hi, > > The bytebuffer-compact patch in icedtea6 was meant to address PR60. This > bug was fixed independently in openjdk6 as 6593946: (bf) > X-Buffer.compact() does not discard mark as specified. Since the fix was > applied upstream, the icedtea patch was modified so it did not conflict > with upstream. > > The openjdk6 fix introduces a new method discardMark() in > java.nio.Buffer, which is simply "mark = -1". The icedtea6 patch (as it > stands currently) introduces a new method clearMark() (in addition to > the discardMark() which is used elsewhere in the jdk) which does the > exact same thing, and then replaces all uses of "mark = -1" in > java.nio.Buffer class with clearMark(). IMHO, this patch is useless and > should be dropped. > > The IcedTea7 version of the patch can also be dropped, but at least that > just replaces "mark = -1" with discardMark() and does not introduce any > new methods. > > Any thoughts or concerns? > > ChangeLog > 2011-04-21 Omair Majid > > * Makefile.am (ICEDTEA_PATCHES): Drop bytebuffer-compact.patch > * patches/bytebuffer-compact.patch: Remove useless patch. > I didnt get this email back, so I suppose others might not have received it either. Apologies if you have already seen it. Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-remove-bytebuffer-patch.patch Type: text/x-patch Size: 2147 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110421/9e905e4b/icedtea6-remove-bytebuffer-patch.patch From omajid at icedtea.classpath.org Thu Apr 21 10:09:20 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Thu, 21 Apr 2011 17:09:20 +0000 Subject: /hg/icedtea: Fix typo in clean-add-cacao target in Makefile.am Message-ID: changeset 663791bf75c7 in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=663791bf75c7 author: Omair Majid date: Thu Apr 21 13:09:00 2011 -0400 Fix typo in clean-add-cacao target in Makefile.am diffstat: ChangeLog | 4 ++++ Makefile.am | 2 +- 2 files changed, 5 insertions(+), 1 deletions(-) diffs (23 lines): diff -r a4851a2bf343 -r 663791bf75c7 ChangeLog --- a/ChangeLog Wed Apr 20 14:58:03 2011 -0400 +++ b/ChangeLog Thu Apr 21 13:09:00 2011 -0400 @@ -1,3 +1,7 @@ +2011-04-21 Omair Majid + + * Makefile.am (clean-add-cacao): Fix typo. + 2011-04-20 Omair Majid * Makefile.am (stamps/remove-intree-libraries.stamp): Typo in file name. diff -r a4851a2bf343 -r 663791bf75c7 Makefile.am --- a/Makefile.am Wed Apr 20 14:58:03 2011 -0400 +++ b/Makefile.am Thu Apr 21 13:09:00 2011 -0400 @@ -2026,7 +2026,7 @@ clean-add-cacao: rm -rf $(BUILD_JRE_ARCH_DIR)/cacao - if [ -e $(BUILD_DEBUG_JRE_ARCH_DIR)/jvm.cfg ] ; then \ + if [ -e $(BUILD_JRE_ARCH_DIR)/jvm.cfg ] ; then \ sed -i 's#-cacao KNOWN#-cacao ERROR#' $(BUILD_JRE_ARCH_DIR)/jvm.cfg ; \ fi rm -f stamps/add-cacao.stamp From omajid at redhat.com Thu Apr 21 09:48:29 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 21 Apr 2011 12:48:29 -0400 Subject: RFC: Forward port icedtea6's debug-dir patch to icedtea7 Message-ID: <4DB05FDD.1070509@redhat.com> Hi, The debug-dir patch from icedtea6 needs to be added to icedtea7. Without this patch, a 'make icedtea-debug' creates a openjdk.build-debug dir which is essentially empty, but places the build in actually (on my macine) linux-amd64-debug under the current directory. The attached patch is the trivial port. Okay to commit? ChangeLog: 2011-04-21 Omair Majid * Makefile.am (ICEDTEA_PATCHES): Add debug-dir.patch * patches/debug-dir.patch: New file. Forward port from icedtea6. Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea7-forward-port-debug-dir.patch Type: text/x-patch Size: 1695 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110421/12256041/icedtea7-forward-port-debug-dir.patch From omajid at icedtea.classpath.org Thu Apr 21 10:20:56 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Thu, 21 Apr 2011 17:20:56 +0000 Subject: /hg/icedtea: Update cacao patches to apply to updated OpenJDK so... Message-ID: changeset bf3fe6f6ddf4 in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=bf3fe6f6ddf4 author: Omair Majid date: Thu Apr 21 13:20:10 2011 -0400 Update cacao patches to apply to updated OpenJDK sources diffstat: ChangeLog | 5 +++++ patches/cacao/ignore-tests.patch | 2 +- patches/cacao/launcher.patch | 2 +- 3 files changed, 7 insertions(+), 2 deletions(-) diffs (36 lines): diff -r 663791bf75c7 -r bf3fe6f6ddf4 ChangeLog --- a/ChangeLog Thu Apr 21 13:09:00 2011 -0400 +++ b/ChangeLog Thu Apr 21 13:20:10 2011 -0400 @@ -1,3 +1,8 @@ +2011-04-21 Omair Majid + + * patches/cacao/ignore-tests.patch: Update to apply on new sources. + * patches/cacao/launcher.patch: Likewise. + 2011-04-21 Omair Majid * Makefile.am (clean-add-cacao): Fix typo. diff -r 663791bf75c7 -r bf3fe6f6ddf4 patches/cacao/ignore-tests.patch --- a/patches/cacao/ignore-tests.patch Thu Apr 21 13:09:00 2011 -0400 +++ b/patches/cacao/ignore-tests.patch Thu Apr 21 13:20:10 2011 -0400 @@ -2,7 +2,7 @@ --- openjdk.orig/jdk/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2010-05-10 15:04:14.000000000 +0100 +++ openjdk/jdk/test/java/util/concurrent/BlockingQueue/ProducerConsumerLoops.java 2010-05-10 23:42:41.000000000 +0100 @@ -37,6 +37,7 @@ - * @compile ProducerConsumerLoops.java + * @compile -source 1.5 ProducerConsumerLoops.java * @run main/timeout=3600 ProducerConsumerLoops * @summary multiple producers and consumers using blocking queues + * @ignore cacao test hog, ignore for the sake of buildds diff -r 663791bf75c7 -r bf3fe6f6ddf4 patches/cacao/launcher.patch --- a/patches/cacao/launcher.patch Thu Apr 21 13:09:00 2011 -0400 +++ b/patches/cacao/launcher.patch Thu Apr 21 13:20:10 2011 -0400 @@ -30,7 +30,7 @@ args.argc = argc; @@ -1931,7 +1935,17 @@ - args.classname = classname; + args.what = what; args.ifn = *ifn; - rslt = ContinueInNewThread0(JavaMain, threadStackSize, (void*)&args); From omajid at redhat.com Thu Apr 21 10:22:20 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 21 Apr 2011 13:22:20 -0400 Subject: IcedTea7 build failed for 2cd959df7e7a In-Reply-To: <20110420225155.GB29985@rivendell.middle-earth.co.uk> References: <20110420015650.GM29985@rivendell.middle-earth.co.uk> <1303282920.11416.11.camel@springer.wildebeest.org> <20110420142258.GS29985@rivendell.middle-earth.co.uk> <4DAF23B6.1010907@redhat.com> <20110420225155.GB29985@rivendell.middle-earth.co.uk> Message-ID: <4DB067CC.4010608@redhat.com> On 04/20/2011 06:51 PM, Dr Andrew John Hughes wrote: > On 14:19 Wed 20 Apr , Omair Majid wrote: >>> Yes, well I haven't tested CACAO in a while. It's not high on my list of priorities. >>> Getting the basic build working tends to be more important :-) >> >> I dug into the cacao errors, and it turns out there are some real >> issues. The attached patch updates the cacao patches to apply, but it is >> not sufficient. Cacao relies on hpi which was removed in OpenJDK7. Some >> of the hpi methods are trivial (Close(int) becomes ::close(int)), but >> others (like NativePath(char*)) are non-trivial. I suppose I can copy >> over the implementation of those methods from hotspot, but I would >> prefer to avoid doing this as an icedtea patch. Perhaps upstream cacao >> should be taking care of this. >> > > I was aware there might be a HPI issue. Feel free to apply the patch below (with a ChangeLog). I have pushed the patch, but I am not sure how useful it will be given that ./configure on CACAO fails. > I think the CACAO developers need to sort the bigger issue if they want to retain support in > IcedTea7. > Would that be the upstream CACAO developers? or the developers maintaining it in IcdTea7? Who should I ping? Thanks, Ommair From benjamin at smedbergs.us Thu Apr 21 11:08:38 2011 From: benjamin at smedbergs.us (Benjamin Smedberg) Date: Thu, 21 Apr 2011 14:08:38 -0400 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <20110421153134.GC7494@redhat.com> References: <4DADADC8.7010404@icyb.net.ua> <4DADCF06.8080803@smedbergs.us> <4DADD105.30103@icyb.net.ua> <20110421153134.GC7494@redhat.com> Message-ID: <4DB072A6.6030804@smedbergs.us> On 4/21/2011 11:31 AM, Deepak Bhole wrote: > > I have modified the plugin to use NPN_GetURLNotify instead of > NPN_GetURL. The former is non-blocking, and thus allows the plugin to > continue to service requests. They are both non-blocking. --BDS From dbhole at redhat.com Thu Apr 21 11:30:34 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 21 Apr 2011 14:30:34 -0400 Subject: firefox 4: problem with NPN_GetURL target=_self In-Reply-To: <4DB072A6.6030804@smedbergs.us> References: <4DADADC8.7010404@icyb.net.ua> <4DADCF06.8080803@smedbergs.us> <4DADD105.30103@icyb.net.ua> <20110421153134.GC7494@redhat.com> <4DB072A6.6030804@smedbergs.us> Message-ID: <20110421183033.GD7494@redhat.com> * Benjamin Smedberg [2011-04-21 14:09]: > On 4/21/2011 11:31 AM, Deepak Bhole wrote: > > > >I have modified the plugin to use NPN_GetURLNotify instead of > >NPN_GetURL. The former is non-blocking, and thus allows the plugin to > >continue to service requests. > They are both non-blocking. > I see. I was going by the documentation[1] for NPN_GetURL that says this: The plug-in developer cannot influence the way that the browser handles NPN_GetURL(). It is typically asynchronous but this is not guaranteed. Wouldn't that mean that the non-blocking nature is not guaranteed? Or am I misunderstanding it? 1: https://developer.mozilla.org/en/NPN_GetURL Cheers, Deepak > --BDS > > _______________________________________________ > dev-tech-plugins mailing list > dev-tech-plugins at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-plugins From omajid at redhat.com Thu Apr 21 12:24:04 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 21 Apr 2011 15:24:04 -0400 Subject: RFC: remove unneeded parts of the lcms patch in icedtea6 Message-ID: <4DB08454.2080309@redhat.com> Hi, The attached patch removes redundant parts of the lcms patch (patches/lcms.patch) in icedtea6. These parts are performing null checks which are not needed. In the case of the first chunk, the null check is redundant (a check is performed a few lines before). The second chunk is just a stylistic change, from (!var) to (var == null). The third chunk is also redundant as a null pointer would have caused issues before getting to that line. Okay to commit? ChangeLog: 2011-04-21 Omair Majid * patches/lcms.patch: Remove useless chunks in the patch. Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-remove-redundant-lcms-chunks.patch Type: text/x-patch Size: 1677 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110421/5290de49/icedtea6-remove-redundant-lcms-chunks.patch From ahughes at redhat.com Thu Apr 21 14:51:22 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 21 Apr 2011 22:51:22 +0100 Subject: RFC: drop bytebuffer-compact patch from icedtea6 In-Reply-To: <4DB057B6.9080800@redhat.com> References: <4DB051A1.5030005@redhat.com> <4DB057B6.9080800@redhat.com> Message-ID: <20110421215122.GH29985@rivendell.middle-earth.co.uk> On 12:13 Thu 21 Apr , Omair Majid wrote: > On 04/21/2011 11:47 AM, Omair Majid wrote: > > Hi, > > > > The bytebuffer-compact patch in icedtea6 was meant to address PR60. This > > bug was fixed independently in openjdk6 as 6593946: (bf) > > X-Buffer.compact() does not discard mark as specified. Since the fix was > > applied upstream, the icedtea patch was modified so it did not conflict > > with upstream. > > > > The openjdk6 fix introduces a new method discardMark() in > > java.nio.Buffer, which is simply "mark = -1". The icedtea6 patch (as it > > stands currently) introduces a new method clearMark() (in addition to > > the discardMark() which is used elsewhere in the jdk) which does the > > exact same thing, and then replaces all uses of "mark = -1" in > > java.nio.Buffer class with clearMark(). IMHO, this patch is useless and > > should be dropped. > > > > The IcedTea7 version of the patch can also be dropped, but at least that > > just replaces "mark = -1" with discardMark() and does not introduce any > > new methods. > > > > Any thoughts or concerns? > > > > ChangeLog > > 2011-04-21 Omair Majid > > > > * Makefile.am (ICEDTEA_PATCHES): Drop bytebuffer-compact.patch > > * patches/bytebuffer-compact.patch: Remove useless patch. > > > > I didnt get this email back, so I suppose others might not have received > it either. Apologies if you have already seen it. > No, this is the first time I saw this e-mail. The patch was previously discussed here: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-April/005352.html I'm for dumping it from both 6 and 7. Please update http://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches to say it has been dropped too. We probably need to clone and edit that page for 7 too. The 6 one also needs updating. > Cheers, > Omair > diff -r 307d19e0cca0 Makefile.am > --- a/Makefile.am Tue Apr 12 15:56:56 2011 +0200 > +++ b/Makefile.am Thu Apr 21 11:36:45 2011 -0400 > @@ -224,7 +224,6 @@ > patches/headers-hotspot.patch \ > patches/gcc-suffix.patch \ > patches/hotspot/$(HSBUILD)/gcc-suffix.patch \ > - patches/bytebuffer-compact.patch \ > patches/memory-limits.patch \ > patches/libraries.patch \ > patches/javafiles.patch \ > diff -r 307d19e0cca0 patches/bytebuffer-compact.patch > --- a/patches/bytebuffer-compact.patch Tue Apr 12 15:56:56 2011 +0200 > +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 > @@ -1,62 +0,0 @@ > ---- ../openjdkb23/openjdk.old/jdk/src/share/classes/java/nio/Buffer.java 2007-10-30 04:36:08.000000000 -0400 > -+++ openjdk/jdk/src/share/classes/java/nio/Buffer.java 2007-11-13 13:33:28.000000000 -0500 > -@@ -234,8 +234,8 @@ > - if ((newPosition > limit) || (newPosition < 0)) > - throw new IllegalArgumentException(); > - position = newPosition; > -- if (mark > position) mark = -1; > -- return this; > -+ if (mark > position) clearMark(); > -+ return this; > - } > - > - /** > -@@ -266,8 +266,8 @@ > - throw new IllegalArgumentException(); > - limit = newLimit; > - if (position > limit) position = limit; > -- if (mark > limit) mark = -1; > -- return this; > -+ if (mark > position) clearMark(); > -+ return this; > - } > - > - /** > -@@ -319,8 +319,8 @@ > - public final Buffer clear() { > - position = 0; > - limit = capacity; > -- mark = -1; > -- return this; > -+ clearMark(); > -+ return this; > - } > - > - /** > -@@ -347,7 +347,7 @@ > - public final Buffer flip() { > - limit = position; > - position = 0; > -- mark = -1; > -+ clearMark(); > - return this; > - } > - > -@@ -368,7 +368,7 @@ > - */ > - public final Buffer rewind() { > - position = 0; > -- mark = -1; > -+ clearMark(); > - return this; > - } > - > -@@ -547,4 +547,8 @@ > - throw new IndexOutOfBoundsException(); > - } > - > -+ final void clearMark() { // package-private > -+ mark = -1; > -+ } > -+ > - } -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 21 14:59:42 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 21 Apr 2011 22:59:42 +0100 Subject: [icedtea-web] RFC: PR618 - Can't install OpenDJ, JavaWebStart fails with Input stream is null error. In-Reply-To: <4DA8B3FD.1020002@redhat.com> References: <4D3F27BE.9060300@redhat.com> <20110126000318.GF18564@rivendell.middle-earth.co.uk> <4D4095C8.4020603@redhat.com> <4D7E2F47.2050807@redhat.com> <20110316204054.GH29289@rivendell.middle-earth.co.uk> <4D822201.7000906@redhat.com> <4DA878AE.8080301@redhat.com> <20110415205544.GI29287@rivendell.middle-earth.co.uk> <4DA8B3FD.1020002@redhat.com> Message-ID: <20110421215942.GJ29985@rivendell.middle-earth.co.uk> On 17:09 Fri 15 Apr , Omair Majid wrote: > On 04/15/2011 04:55 PM, Dr Andrew John Hughes wrote: > > > > Can you start a clean thread with the current version of the patch? > > The previous e-mail was pretty unreadable for me. > > Here you go. Attached. > > As explained earlier, it fixes PR618, buy allowing lazy loading to work > when trying to find resources using getResource(s)/findResource(s). > > Any thoughts or comments? > > Cheers, > Omair Inline. > diff -r 5454292b3fae netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java > --- a/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Thu Mar 10 15:42:01 2011 -0500 > +++ b/netx/net/sourceforge/jnlp/runtime/JNLPClassLoader.java Mon Mar 14 11:07:15 2011 -0400 > @@ -40,7 +40,6 @@ > import java.util.List; > import java.util.Map; > import java.util.TreeSet; > -import java.util.Vector; > import java.util.jar.JarEntry; > import java.util.jar.JarFile; > > @@ -1123,31 +1122,54 @@ > /** > * Finds the resource in this, the parent, or the extension > * class loaders. > + * > + * @return a URL for the resource, or null > + * if the resource could not be found. > */ > - public URL getResource(String name) { > - URL result = super.getResource(name); > + @Override > + public URL findResource(String name) { > + URL result = null; > > - for (int i = 1; i < loaders.length; i++) > - if (result == null) > - result = loaders[i].getResource(name); > + try { > + Enumeration e = findResources(name); Just a stylistic thing, but it's usually Enumeration without the space. > + if (e.hasMoreElements()) { > + result = e.nextElement(); > + } > + } catch (IOException e) { > + // continue Should we not at least log this if debugging mode is on? > + private Enumeration findResourcesBySearching(String name) throws IOException { > + List resources = new ArrayList(); > Enumeration e; > > for (int i = 0; i < loaders.length; i++) { > + // TODO check if this will blow up or not > + // if loaders[1].getResource() is called, wont it call getResource() on > + // the original caller? infinite recursion? > > if (loaders[i] == this) > e = super.findResources(name); > @@ -1166,7 +1188,7 @@ > resources.add(e.nextElement()); > } > > - return resources.elements(); > + return Collections.enumeration(resources); > } > Probably asked this last time, but remind why we return an Enumeration and not an Iterator when resources is a List? > /** -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at icedtea.classpath.org Thu Apr 21 16:59:54 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Thu, 21 Apr 2011 23:59:54 +0000 Subject: /hg/icedtea6: Drop bytebuffer-compact.patch Message-ID: changeset 92ce3a01d889 in /hg/icedtea6 details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=92ce3a01d889 author: Omair Majid date: Thu Apr 21 19:59:32 2011 -0400 Drop bytebuffer-compact.patch The bytebuffer-compact patch adds a (package-private) method clearMark to reset the mark. Upstream already addressed this problem: 6593946: (bf) X-Buffer.compact() does not discard mark as specified. The upstream fix adds a method discardMark(), and updates the rest of the JDK to use that method. The clearMark() method added by this patch is not used anywhere and can be dropped safely. diffstat: ChangeLog | 5 +++ Makefile.am | 1 - patches/bytebuffer-compact.patch | 61 ---------------------------------------- 3 files changed, 5 insertions(+), 62 deletions(-) diffs (89 lines): diff -r 307d19e0cca0 -r 92ce3a01d889 ChangeLog --- a/ChangeLog Tue Apr 12 15:56:56 2011 +0200 +++ b/ChangeLog Thu Apr 21 19:59:32 2011 -0400 @@ -1,3 +1,8 @@ +2011-04-21 Omair Majid + + * patches/bytebuffer-compact.patch: Drop useless patch. + * Makefile.am (ICEDTEA_PATCHES): Do not apply dropped patch. + 2011-04-12 Xerxes R??nby PR689: Shark fails to find LLVM 2.9 System headers during build diff -r 307d19e0cca0 -r 92ce3a01d889 Makefile.am --- a/Makefile.am Tue Apr 12 15:56:56 2011 +0200 +++ b/Makefile.am Thu Apr 21 19:59:32 2011 -0400 @@ -224,7 +224,6 @@ patches/headers-hotspot.patch \ patches/gcc-suffix.patch \ patches/hotspot/$(HSBUILD)/gcc-suffix.patch \ - patches/bytebuffer-compact.patch \ patches/memory-limits.patch \ patches/libraries.patch \ patches/javafiles.patch \ diff -r 307d19e0cca0 -r 92ce3a01d889 patches/bytebuffer-compact.patch --- a/patches/bytebuffer-compact.patch Tue Apr 12 15:56:56 2011 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,62 +0,0 @@ ---- ../openjdkb23/openjdk.old/jdk/src/share/classes/java/nio/Buffer.java 2007-10-30 04:36:08.000000000 -0400 -+++ openjdk/jdk/src/share/classes/java/nio/Buffer.java 2007-11-13 13:33:28.000000000 -0500 -@@ -234,8 +234,8 @@ - if ((newPosition > limit) || (newPosition < 0)) - throw new IllegalArgumentException(); - position = newPosition; -- if (mark > position) mark = -1; -- return this; -+ if (mark > position) clearMark(); -+ return this; - } - - /** -@@ -266,8 +266,8 @@ - throw new IllegalArgumentException(); - limit = newLimit; - if (position > limit) position = limit; -- if (mark > limit) mark = -1; -- return this; -+ if (mark > position) clearMark(); -+ return this; - } - - /** -@@ -319,8 +319,8 @@ - public final Buffer clear() { - position = 0; - limit = capacity; -- mark = -1; -- return this; -+ clearMark(); -+ return this; - } - - /** -@@ -347,7 +347,7 @@ - public final Buffer flip() { - limit = position; - position = 0; -- mark = -1; -+ clearMark(); - return this; - } - -@@ -368,7 +368,7 @@ - */ - public final Buffer rewind() { - position = 0; -- mark = -1; -+ clearMark(); - return this; - } - -@@ -547,4 +547,8 @@ - throw new IndexOutOfBoundsException(); - } - -+ final void clearMark() { // package-private -+ mark = -1; -+ } -+ - } From omajid at icedtea.classpath.org Thu Apr 21 17:12:26 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Fri, 22 Apr 2011 00:12:26 +0000 Subject: /hg/icedtea: Drop patches/bytebuffer-compact.patch Message-ID: changeset 0f9261320112 in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=0f9261320112 author: Omair Majid date: Thu Apr 21 20:12:07 2011 -0400 Drop patches/bytebuffer-compact.patch The patch only contained stylistic changes. The original bug addressed by the patch, 6593946: (bf) X-Buffer.compact() does not discard mark as specified, was fixed upstream a while back. diffstat: ChangeLog | 6 +++ Makefile.am | 1 - patches/icedtea-bytebuffer-compact.patch | 53 -------------------------------- 3 files changed, 6 insertions(+), 54 deletions(-) diffs (82 lines): diff -r bf3fe6f6ddf4 -r 0f9261320112 ChangeLog --- a/ChangeLog Thu Apr 21 13:20:10 2011 -0400 +++ b/ChangeLog Thu Apr 21 20:12:07 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-21 Omair Majid + + * patches/bytebuffer-compact.patch: Drop patch. It only contained + stylistic changes. + * Makefile.am: Do not apply dropped patch. + 2011-04-21 Omair Majid * patches/cacao/ignore-tests.patch: Update to apply on new sources. diff -r bf3fe6f6ddf4 -r 0f9261320112 Makefile.am --- a/Makefile.am Thu Apr 21 13:20:10 2011 -0400 +++ b/Makefile.am Thu Apr 21 20:12:07 2011 -0400 @@ -242,7 +242,6 @@ patches/hotspot/$(HSBUILD)/icedtea-headers.patch \ patches/icedtea-gcc-suffix.patch \ patches/hotspot/$(HSBUILD)/icedtea-gcc-suffix.patch \ - patches/icedtea-bytebuffer-compact.patch \ patches/hotspot/$(HSBUILD)/icedtea-memory-limits.patch \ patches/icedtea-sunsrc.patch \ patches/icedtea-libraries.patch \ diff -r bf3fe6f6ddf4 -r 0f9261320112 patches/icedtea-bytebuffer-compact.patch --- a/patches/icedtea-bytebuffer-compact.patch Thu Apr 21 13:20:10 2011 -0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,54 +0,0 @@ ---- ../openjdkb23/openjdk.old/jdk/src/share/classes/java/nio/Buffer.java 2007-10-30 04:36:08.000000000 -0400 -+++ openjdk/jdk/src/share/classes/java/nio/Buffer.java 2007-11-13 13:33:28.000000000 -0500 -@@ -234,8 +234,8 @@ - if ((newPosition > limit) || (newPosition < 0)) - throw new IllegalArgumentException(); - position = newPosition; -- if (mark > position) mark = -1; -- return this; -+ if (mark > position) discardMark(); -+ return this; - } - - /** -@@ -266,8 +266,8 @@ - throw new IllegalArgumentException(); - limit = newLimit; - if (position > limit) position = limit; -- if (mark > limit) mark = -1; -- return this; -+ if (mark > position) discardMark(); -+ return this; - } - - /** -@@ -319,8 +319,8 @@ - public final Buffer clear() { - position = 0; - limit = capacity; -- mark = -1; -- return this; -+ discardMark(); -+ return this; - } - - /** -@@ -347,7 +347,7 @@ - public final Buffer flip() { - limit = position; - position = 0; -- mark = -1; -+ discardMark(); - return this; - } - -@@ -368,7 +368,7 @@ - */ - public final Buffer rewind() { - position = 0; -- mark = -1; -+ discardMark(); - return this; - } - - From omajid at redhat.com Thu Apr 21 17:16:58 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 21 Apr 2011 20:16:58 -0400 Subject: RFC: drop bytebuffer-compact patch from icedtea6 In-Reply-To: <20110421215122.GH29985@rivendell.middle-earth.co.uk> References: <4DB051A1.5030005@redhat.com> <4DB057B6.9080800@redhat.com> <20110421215122.GH29985@rivendell.middle-earth.co.uk> Message-ID: <4DB0C8FA.1090800@redhat.com> On 04/21/2011 05:51 PM, Dr Andrew John Hughes wrote: > On 12:13 Thu 21 Apr , Omair Majid wrote: >>> On 04/21/2011 11:47 AM, Omair Majid wrote: >>>>> Hi, >>>>> >>>>> The bytebuffer-compact patch in icedtea6 was meant to address >>>>> PR60. This bug was fixed independently in openjdk6 as >>>>> 6593946: (bf) X-Buffer.compact() does not discard mark as >>>>> specified. Since the fix was applied upstream, the icedtea >>>>> patch was modified so it did not conflict with upstream. >>>>> >>>>> The openjdk6 fix introduces a new method discardMark() in >>>>> java.nio.Buffer, which is simply "mark = -1". The icedtea6 >>>>> patch (as it stands currently) introduces a new method >>>>> clearMark() (in addition to the discardMark() which is used >>>>> elsewhere in the jdk) which does the exact same thing, and >>>>> then replaces all uses of "mark = -1" in java.nio.Buffer >>>>> class with clearMark(). IMHO, this patch is useless and >>>>> should be dropped. >>>>> >>>>> The IcedTea7 version of the patch can also be dropped, but at >>>>> least that just replaces "mark = -1" with discardMark() and >>>>> does not introduce any new methods. >>>>> >>>>> Any thoughts or concerns? >>>>> >>>>> >>> >>> I didnt get this email back, so I suppose others might not have >>> received it either. Apologies if you have already seen it. >>> > No, this is the first time I saw this e-mail. > > The patch was previously discussed > here:http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-April/005352.html > > Yes, I saw that link, but I dont think we reached a conclusion there about whether to drop the patch or not. > I'm for dumping it from both 6 and 7. > Done. I have dropped it from both. > Please updatehttp://icedtea.classpath.org/wiki/IcedTea_JDK6_Patches > to say it has been dropped too. > Done, I think. I didnt add it in any "Made obsolete by OpenJDK6..." section. Should I do that? > We probably need to clone and edit that page for 7 too. The 6 one > also needs updating. > I am going through the icedtea6 patches right now to forward port/drop them. Once I am done, I will try and create a page for 7. Cheers, Omair From ptisnovs at redhat.com Fri Apr 22 07:07:29 2011 From: ptisnovs at redhat.com (Pavel Tisnovsky) Date: Fri, 22 Apr 2011 16:07:29 +0200 Subject: Memory leak in IcedTea7 - loading resources from JAR files Message-ID: <4DB18BA1.2090608@redhat.com> Hi all, I think there's a memory leak in IcedTea7 which occurs during loading resources from JAR files. Simple reproducer is stored in an attachment. This reproducer tries to read contents of one file (it's a copy of GNU licence ;-) from JAR file in a loop. If this test is started using IcedTea6 (6-1.9.7 to be precise), heap space is quite small and does not increasing as can be seen on jconsole screenshot "IcedTea6-1.9.7.png" which is stored in an attachment. But under IcedTea7-1.14 heap size is increasing - you can see this behaviour on screenshot "IcedTea7-1.14.png". And in some circumstances (using relative small maximum heap size, for example), the test fails. This can be simply reproduced: jawa28:~/1/mem_leak/$ /jck/icedtea/openjdk.build/j2sdk-image/bin/java -Xmx40M -cp .:resource.jar LoadResource iteration# 0 ... ... ... iteration# 2038 Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.zip.InflaterInputStream.(InflaterInputStream.java:88) at java.util.zip.ZipFile$1.(ZipFile.java:362) at java.util.zip.ZipFile.getInputStream(ZipFile.java:362) at java.util.jar.JarFile.getInputStream(JarFile.java:401) at sun.net.www.protocol.jar.JarURLConnection.getInputStream(JarURLConnection.java:162) at java.net.URL.openStream(URL.java:1035) at java.lang.ClassLoader.getSystemResourceAsStream(ClassLoader.java:1372) at LoadResource.main(LoadResource.java:12) Cheers Pavel -------------- next part -------------- A non-text attachment was scrubbed... Name: memory_leak.tar.gz Type: application/x-gzip Size: 118902 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110422/bdaeb5b1/memory_leak.tar.gz From omajid at redhat.com Fri Apr 22 07:57:43 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 22 Apr 2011 10:57:43 -0400 Subject: IcedTea6 build failed for 92ce3a01d889 In-Reply-To: References: Message-ID: <4DB19767.9020102@redhat.com> On 04/21/2011 08:41 PM, Mark Wielaard wrote: > The current IcedTea build fails. > > More info at http://builder.wildebeest.org/icedtea/icedtea6/ > > Possibly, but not necessarily, because of one of these changes: > Sorry about breaking the build. I was _not_ expecting this to happen - I had grepped through OpenJDK code to make sure that clearMark() was not being used. > rev: 92ce3a01d889 > user: Omair Majid > date: Thu Apr 21 19:59:32 2011 -0400 > > Drop bytebuffer-compact.patch > > The bytebuffer-compact patch adds a (package-private) method clearMark to reset > the mark. Upstream already addressed this problem: > 6593946: (bf) X-Buffer.compact() does not discard mark as specified. > The upstream fix adds a method discardMark(), and updates the rest of the JDK > to use that method. The clearMark() method added by this patch is not used > anywhere and can be dropped safely. > > > Last part of build log: > > patching file openjdk-ecj/hotspot/make/linux/Makefile > for dir in openjdk-ecj/jdk/src/share/classes/com/sun/jdi openjdk-ecj/jdk/src/share/classes/com/sun/net/httpserver openjdk-ecj/jdk/src/share/classes/com/sun/tools/jdi openjdk-ecj/jdk/src/share/classes/java/io openjdk-ecj/jdk/src/share/classes/java/security/cert openjdk-ecj/jdk/src/share/classes/java/util openjdk-ecj/jdk/src/share/classes/java/rmi openjdk-ecj/jdk/src/share/classes/sun/awt/ openjdk-ecj/jdk/src/share/classes/sun/nio/cs openjdk-ecj/jdk/src/share/classes/sun/rmi/rmic openjdk-ecj/jdk/src/share/classes/sun/tools/java openjdk-ecj/jdk/src/share/classes/javax/net/ssl openjdk-ecj/jdk/src/share/classes/javax/script openjdk-ecj/jdk/src/share/classes/javax/security/auth/kerberos openjdk-ecj/jdk/src/share/classes/javax/security/sasl openjdk-ecj/langtools/src/share/classes/com/sun/mirror openjdk-ecj/langtools/src/share/classes/com/sun/tools/apt ; \ > do \ > /usr/bin/find /usr/local/build/icedtea6-build/$dir -name '*.java'>> rt-source-files.txt; \ > done > for files in openjdk-ecj/jdk/src/share/classes/javax/swing/plaf/basic/BasicDirectoryModel.java openjdk-ecj/jdk/src/share/classes/javax/management/StandardMBean.java openjdk-ecj/jdk/src/share/classes/com/sun/java/swing/plaf/nimbus/NimbusLookAndFeel.java ; \ > do \ > echo $files>> rt-source-files.txt ; \ > done > mkdir -p lib/rt > /usr/local/build/icedtea6-build/bootstrap/jdk1.6.0/bin/javac -g -encoding utf-8 -source 6 -target 6 -d lib/rt \ > -sourcepath /usr/local/build/icedtea6/generated:openjdk-ecj/jdk/src/share/classes:openjdk-ecj/jdk/src/solaris/classes:openjdk-ecj/langtools/src/share/classes:openjdk-ecj/corba/src/share/classes -bootclasspath \'\' \ > -classpath /usr/lib/jvm/java-gcj/jre/lib/rt.jar \ > @rt-source-files.txt ; > incorrect classpath: '' > Annotation processing got disabled, since it requires a 1.6 compliant JVM > ---------- > 1. ERROR in /usr/local/build/icedtea6/generated/java/nio/HeapCharBuffer.java (at line 225) > clearMark(); > ^^^^^^^^^ > The method clearMark() is undefined for the type HeapCharBuffer > ---------- I am quite confused about the purpose of the generated/java/nio directory. It contains java classes. Looking at the OpenJDK6's makefiles, it generates all these classes already. For example generated contains generated/java/nio/HeapCharBuffer.java. OpenJDK6 generates the class HeapCharBuffer.java anyway: (jdk/make/java/nio/Makefile) $(BUF_GEN)/HeapCharBuffer.java: $(BUF_SRC)/Heap-X-Buffer.java $(GEN_BUFFER_SH) $(prep-target) @$(RM) $@.temp TYPE=char SRC=$< DST=$@.temp $(GEN_BUFFER_CMD) $(MV) $@.temp $@ In fact, I just tried out a new build after rm -rf'ing generated/java/nio. The build completed successfully. The rt.jar produced in the new build contains all the classes contained in rt.jar from an older IcedTea6 build. All the java.nio.* jtreg tests pass. This makes it seem like generated/java/nio/ is redundant. Does anyone have a clue on why generated/java/nio is present in IcedTea6? Should it be dropped? Meanwhile, should I add back the bytebuffer-compact patch to un-break the build? Sorry about the breakage. Thanks, Omair From omajid at redhat.com Fri Apr 22 08:06:23 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 22 Apr 2011 11:06:23 -0400 Subject: RFC: Forward port icedtea6's debug-dir patch to icedtea7 In-Reply-To: <4DB05FDD.1070509@redhat.com> References: <4DB05FDD.1070509@redhat.com> Message-ID: <4DB1996F.2090005@redhat.com> On 04/21/2011 12:48 PM, Omair Majid wrote: > Hi, > > The debug-dir patch from icedtea6 needs to be added to icedtea7. Without > this patch, a 'make icedtea-debug' creates a openjdk.build-debug dir > which is essentially empty, and places the build in actually (on my > machine) linux-amd64-debug under the current directory. > > The attached patch is the trivial port. Okay to commit? > > ChangeLog: > 2011-04-21 Omair Majid > > * Makefile.am (ICEDTEA_PATCHES): Add debug-dir.patch > * patches/debug-dir.patch: New file. Forward port from icedtea6. Looks like another patch that did not make it back to my inbox. Sending again. Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea7-forward-port-debug-dir.patch Type: text/x-patch Size: 1695 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110422/2dd31138/icedtea7-forward-port-debug-dir.patch From omajid at icedtea.classpath.org Fri Apr 22 14:35:43 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Fri, 22 Apr 2011 21:35:43 +0000 Subject: /hg/icedtea6: Revert previous commmit - it broke bootstrap. Message-ID: changeset bc0a045bf271 in /hg/icedtea6 details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=bc0a045bf271 author: Omair Majid date: Fri Apr 22 17:35:11 2011 -0400 Revert previous commmit - it broke bootstrap. diffstat: ChangeLog | 6 +++ Makefile.am | 1 + patches/bytebuffer-compact.patch | 61 ++++++++++++++++++++++++++++++++++++++++ 3 files changed, 68 insertions(+), 0 deletions(-) diffs (90 lines): diff -r 92ce3a01d889 -r bc0a045bf271 ChangeLog --- a/ChangeLog Thu Apr 21 19:59:32 2011 -0400 +++ b/ChangeLog Fri Apr 22 17:35:11 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-22 Omair Majid + + Revert previous patch. + * Makefile.am (ICEDTEA_PATCHES): Apply patch. + * patches/bytebuffer-compact.patch: Add back patch file. + 2011-04-21 Omair Majid * patches/bytebuffer-compact.patch: Drop useless patch. diff -r 92ce3a01d889 -r bc0a045bf271 Makefile.am --- a/Makefile.am Thu Apr 21 19:59:32 2011 -0400 +++ b/Makefile.am Fri Apr 22 17:35:11 2011 -0400 @@ -224,6 +224,7 @@ patches/headers-hotspot.patch \ patches/gcc-suffix.patch \ patches/hotspot/$(HSBUILD)/gcc-suffix.patch \ + patches/bytebuffer-compact.patch \ patches/memory-limits.patch \ patches/libraries.patch \ patches/javafiles.patch \ diff -r 92ce3a01d889 -r bc0a045bf271 patches/bytebuffer-compact.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/bytebuffer-compact.patch Fri Apr 22 17:35:11 2011 -0400 @@ -0,0 +1,62 @@ +--- ../openjdkb23/openjdk.old/jdk/src/share/classes/java/nio/Buffer.java 2007-10-30 04:36:08.000000000 -0400 ++++ openjdk/jdk/src/share/classes/java/nio/Buffer.java 2007-11-13 13:33:28.000000000 -0500 +@@ -234,8 +234,8 @@ + if ((newPosition > limit) || (newPosition < 0)) + throw new IllegalArgumentException(); + position = newPosition; +- if (mark > position) mark = -1; +- return this; ++ if (mark > position) clearMark(); ++ return this; + } + + /** +@@ -266,8 +266,8 @@ + throw new IllegalArgumentException(); + limit = newLimit; + if (position > limit) position = limit; +- if (mark > limit) mark = -1; +- return this; ++ if (mark > position) clearMark(); ++ return this; + } + + /** +@@ -319,8 +319,8 @@ + public final Buffer clear() { + position = 0; + limit = capacity; +- mark = -1; +- return this; ++ clearMark(); ++ return this; + } + + /** +@@ -347,7 +347,7 @@ + public final Buffer flip() { + limit = position; + position = 0; +- mark = -1; ++ clearMark(); + return this; + } + +@@ -368,7 +368,7 @@ + */ + public final Buffer rewind() { + position = 0; +- mark = -1; ++ clearMark(); + return this; + } + +@@ -547,4 +547,8 @@ + throw new IndexOutOfBoundsException(); + } + ++ final void clearMark() { // package-private ++ mark = -1; ++ } ++ + } From omajid at redhat.com Fri Apr 22 14:36:16 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 22 Apr 2011 17:36:16 -0400 Subject: IcedTea6 build failed for 92ce3a01d889 In-Reply-To: <4DB19767.9020102@redhat.com> References: <4DB19767.9020102@redhat.com> Message-ID: <4DB1F4D0.2000200@redhat.com> On 04/22/2011 10:57 AM, Omair Majid wrote: > > Meanwhile, should I add back the bytebuffer-compact patch to un-break > the build? Sorry about the breakage. I have reverted the patch. Thanks, Omair From omajid at redhat.com Fri Apr 22 15:27:19 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 22 Apr 2011 18:27:19 -0400 Subject: RFC: drop parts of patches/icedtea-pr261.patch in icedtea7 Message-ID: <4DB200C7.5080208@redhat.com> Hi, Parts of patches/icedtea-pr261.patch in IcedTea7 were applied independently by upstream [1]. In fact, applying patches/icedtea-pr261.patch causes the file list to contain some files twice. The attached patch drops the upstreamed parts. With the patch applied, there is no change in number/names of files in rt.jar produced. Okay to commit? ChangeLog: 2011-04-22 Omair Majid * patches/icedtea-pr261.patch: Drop chunks fixed upstream. Thanks, Omair [1] http://hg.openjdk.java.net/jdk7/tl/jdk/diff/f06f30b29f36/make/java/nio/FILES_java.gmk -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea7-drop-parts-of-pr261.patch Type: text/x-patch Size: 1376 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110422/5b67a683/icedtea7-drop-parts-of-pr261.patch From omajid at redhat.com Fri Apr 22 15:37:40 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 22 Apr 2011 18:37:40 -0400 Subject: RFC: drop nss-debug.patch in icedtea6 Message-ID: <4DB20334.20706@redhat.com> Hi, The file patches/nss-debug.patch was upstreamed a while back [1]. As a result this patch has been sitting in icedtea6 repo unused. The attached patch drops it. Okay to commit? Thanks, Omair [1] http://hg.openjdk.java.net/jdk6/jdk6/jdk/rev/c3a035784a3a -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-drop-nss-debug.patch Type: text/x-patch Size: 2785 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110422/a645e969/icedtea6-drop-nss-debug.patch From bugzilla-daemon at icedtea.classpath.org Sun Apr 24 05:29:00 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 24 Apr 2011 12:29:00 +0000 Subject: [Bug 698] New: Zero fails to build on bytecodeInterpreter.cpp Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=698 Summary: Zero fails to build on bytecodeInterpreter.cpp Product: IcedTea Version: 7-hg Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Zero AssignedTo: unassigned at icedtea.classpath.org ReportedBy: drazzib at drazzib.com Hi, On Debian autobuilders lastest icedtea7 snapshot FTBFS with the following error : g++-4.5 -DLINUX -D_GNU_SOURCE -DCC_INTERP -DZERO -DIA64 -DZERO_LIBARCH=\"ia64\" -DPRODUCT -I. -I/build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk-boot/hotspot/src/share/vm/prims -I/build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk-boot/hotspot/src/share/vm -I/build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk-boot/hotspot/src/cpu/zero/vm -I/build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk-boot/hotspot/src/os_cpu/linux_zero/vm -I/build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk-boot/hotspot/src/os/linux/vm -I/build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk-boot/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"21.0-b02\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"buildd\"" -DHOTSPOT_LIB_ARCH=\"ia64\" -DJRE_RELEASE_VERSION="\"1.7.0_130-b130\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea7 1.14-pre\"" -DDEB_MULTIARCH="\"ia64-linux-gnu\"" -DDISTRIBUTION_ID="\"Debian GNU/Linux unstable (sid), package 7~b130-1.14~pre0-1\"" -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_zero -DTARGET_ARCH_MODEL_zero -DTARGET_OS_ARCH_linux_zero -DTARGET_OS_ARCH_MODEL_linux_zero -DTARGET_COMPILER_gcc -fpic -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -pipe -g -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -c -MMD -MP -MF ../generated/dependencies/bytecodeInterpreterWithChecks.o.d -o bytecodeInterpreterWithChecks.o ../generated/jvmtifiles/bytecodeInterpreterWithChecks.cpp /build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk-boot/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp: In static member function 'static void BytecodeInterpreter::run(BytecodeInterpreter*)': /build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk-boot/hotspot/src/share/vm/interpreter/bytecodeInterpreter.cpp:2207:29: error: 'java_lang_invoke_CallSite' has not been declared make[8]: *** [bytecodeInterpreter.o] Error 1 make[8]: Leaving directory `/build/buildd-openjdk-7_7~b130-1.14~pre0-1-ia64-bHHc4M/openjdk-7-7~b130-1.14~pre0/build/openjdk.build-boot/hotspot/outputdir/linux_ia64_zero/product' make[7]: *** [the_vm] Error 2 AFAIK, CallSite is part of the implementation of JSR292 : - java.lang.invoke.CallSite was previously (before b135) java.dyn.CallSite : http://blogs.sun.com/jrose/entry/jsr_292_support_in_b135. So I was expected java.dyn.CallSite here... - Gary Benson seems to be working on zero support for JSR292 : http://gbenson.net/?p=240 Full build log can be downloaded here : https://buildd.debian.org/status/fetch.php?pkg=openjdk-7&arch=ia64&ver=7~b130-1.14~pre0-1&stamp=1303642832 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 24 05:33:48 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 24 Apr 2011 12:33:48 +0000 Subject: [Bug 695] [TRACKER] IcedTea7 1.14 Release In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=695 Damien Raude-Morvan changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |drazzib at drazzib.com Depends on| |698 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 24 05:33:49 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 24 Apr 2011 12:33:49 +0000 Subject: [Bug 698] Zero fails to build on bytecodeInterpreter.cpp In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=698 Damien Raude-Morvan changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |695 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 24 09:47:19 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Sun, 24 Apr 2011 16:47:19 +0000 Subject: [Bug 699] New: A problem with libre office Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=699 Summary: A problem with libre office Product: IcedTea Version: unspecified Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: IcedTea6 AssignedTo: unassigned at icedtea.classpath.org ReportedBy: maninred at alice-dsl.net Created an attachment (id=526) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=526) A log Sorry, I cant say what the problem is and what I?ve done. There was just the file which I attach in my document folder. No crashes or something were there. I also use yacy, which may be the problem. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Sun Apr 24 17:17:20 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 25 Apr 2011 00:17:20 +0000 Subject: [Bug 698] Zero fails to build on bytecodeInterpreter.cpp In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=698 Andrew John Hughes changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gnu_andrew at member.fsf.org --- Comment #1 from Andrew John Hughes 2011-04-25 00:17:20 --- We'll be updating to b137 as b130 (the supposed Developer Preview) seems broken in a number of ways. Please retry when that update is in place. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From xiaoqiangnk at gmail.com Sun Apr 24 19:47:51 2011 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Mon, 25 Apr 2011 10:47:51 +0800 Subject: merging of Hotspot with MIPS support Message-ID: Hi guys, I am not sure if this is the right mailing list, if not, could anyone tell me the right mailing list? We have ported Hotspot client to MIPS compatible processors, and code can be got from http://icedtea.classpath.org/hg/openjdk6-mips/. I want to know how to merge the code to Icedtea. Is there a site which describes the steps we should take and what's the requirements? Thank you, Yongqiang. From bugzilla-daemon at icedtea.classpath.org Mon Apr 25 05:15:27 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 25 Apr 2011 12:15:27 +0000 Subject: [Bug 700] New: Error detected by the Java Runtime Environment in libreoffice Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=700 Summary: Error detected by the Java Runtime Environment in libreoffice Product: IcedTea Version: unspecified Platform: 64-bit OS/Version: Linux Status: NEW Severity: minor Priority: P5 Component: IcedTea6 AssignedTo: unassigned at icedtea.classpath.org ReportedBy: karaka22 at gmail.com Recently when running libreoffice I have been getting an error log stating that "A fatal error has been detected by the Java Runtime Environment." The entire message is some 1,000 lines long, so I have included it as an attachment. I am not actually sure how this error originates - it happens very sporadically, but I did not have this error until openoffice was updated to libreoffice. I hadn't even notice that an error had occurred until I found the following attachment in my document folder. It was only in the most recent occurrence that libreoffice gave an indication of an error - it froze and then crashed. Thanks -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Mon Apr 25 05:16:28 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Mon, 25 Apr 2011 12:16:28 +0000 Subject: [Bug 700] Error detected by the Java Runtime Environment in libreoffice In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=700 --- Comment #1 from Kara 2011-04-25 12:16:28 --- Created an attachment (id=527) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=527) hs_err_pid2735.log -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From doko at ubuntu.com Tue Apr 26 00:00:32 2011 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 26 Apr 2011 09:00:32 +0200 Subject: code without sources distributed in 7b130 Message-ID: <4DB66D90.7090006@ubuntu.com> The following code distributed in 7b130 doesn't have any source code, or at least nobody can find it. in langtools: test/tools/javac/T5090006/broken.jar could the source code be added to the test case? in jdk: test/sun/security/pkcs11/nss/lib/ various precompiled shared libraries. Is it necessary to distribute these with the jdk sources? Checked that these files are available on Debian and Ubuntu distributions libsoftokn3.so: in /usr/lib, package libnss3-1d/libnss3 libnss3.so: same libnssckbi.so: in /usr/lib/nss libnspr4.so: in /usr/lib, package libnspr4-0d/libnspr4 libplds4.so: same libplc4.so: same thanks, Matthias From xerxes at zafena.se Tue Apr 26 01:24:30 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Tue, 26 Apr 2011 10:24:30 +0200 Subject: merging of Hotspot with MIPS support In-Reply-To: References: Message-ID: <4DB6813E.4050206@zafena.se> Hi Yongqiang! On 2011-04-25 04:47, Yongqiang Yang wrote: > Hi guys, > > We have ported Hotspot client to MIPS compatible processors, and code > can be got from http://icedtea.classpath.org/hg/openjdk6-mips/. The MIPS ports looks like it are based on OpenJDK6 and Hotspot hs14, the same hotspot used in the IcedTea6-1.8 release. > I want to know how to merge the code to Icedtea. Is there a site > which describes the steps we should take and what's the requirements? In order to merge the MIPS port with IcedTea6 you will have to update the MIPS port to be compatible with the same hotspot used by IcedTea6 HEAD. The IcedTea6-1.8 release branch uses the same hotspot version hs14 as the MIPS port so a merge at this point are easy but its too late to go in because the release branches do not accept new features. The IcedTea6-1.9 release uses hotspot version hs17. The IcedTea6-1.10 release uses hotspot version hs19. The next IcedTea6-1.11 release are currently based on hs20, HEAD. For a merge to happen its required to update the MIPS port to hs20 and merge it against the current development HEAD at: http://icedtea.classpath.org/hg/icedtea6 You can track when the release branches forked from the IcedTea6 tag list: http://icedtea.classpath.org/hg/icedtea6/tags I suggest you start by first checkout the IcedTea6-1.8 branch-point http://icedtea.classpath.org/hg/icedtea6/rev/9420faca6468 and merge at this point. Then pull in the IcedTea6-1.9 branch-point merge and fix any issues when using hs17. Then pull in the IcedTea6-1.10 branch-point merge and fix any issues when using hs19. Then pull in the IcedTea6 developement HEAD, merge and fix any issues when using hs20. When this are done please send in a patch. Cheers Xerxes From bugzilla-daemon at icedtea.classpath.org Tue Apr 26 08:29:17 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 26 Apr 2011 15:29:17 +0000 Subject: [Bug 700] Error detected by the Java Runtime Environment in libreoffice In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=700 Andrew Su changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asu at redhat.com Status|NEW |RESOLVED Resolution| |INVALID --- Comment #2 from Andrew Su 2011-04-26 15:29:17 --- Hello Kara, I took a quick look at the log you have posted, this is an issue with one of the library that openoffice is using: libsvllx.so A segmentation fault occurred and caused the crash. I will close this as invalid, since it is not a crash caused by java. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 26 08:40:34 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 26 Apr 2011 15:40:34 +0000 Subject: [Bug 701] New: Shark hs19 assert(Thread::current()->is_VM_thread()) failed: must be called by VM thread Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=701 Summary: Shark hs19 assert(Thread::current()->is_VM_thread()) failed: must be called by VM thread Product: IcedTea Version: 6-1.9.7 Platform: all OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Shark AssignedTo: unassigned at icedtea.classpath.org ReportedBy: xerxes at zafena.se Testcase build Shark against icedtea6-1.9 with assertions and hs19 enabled: cd icedtea6-1.9 patch -p1 < contrib/mixtech-hacks.patch ./autogen.sh mkdir ../icedtea6-1.9-shark-debug cd ../icedtea6-1.9-shark-debug ../icedtea6-1.9/configure --enable-shark --with-hotspot-build make ... build-bootstrap-javac: [mkdir] Created dir: /home/xerxes/icedtea6-1.9-shark-debug/openjdk.build/langtools/build/bootstrap/gensrc [mkdir] Created dir: /home/xerxes/icedtea6-1.9-shark-debug/openjdk.build/langtools/build/bootstrap/classes [pcompile] Generating 7 resource files to /home/xerxes/icedtea6-1.9-shark-debug/openjdk.build/langtools/build/bootstrap/gensrc [copy] Copying 1 file to /home/xerxes/icedtea6-1.9-shark-debug/openjdk.build/langtools/build/bootstrap/gensrc [pcompile] Generating 1 resource files to /home/xerxes/icedtea6-1.9-shark-debug/openjdk.build/langtools/build/bootstrap/gensrc [javac] Compiling 8 source files to /home/xerxes/icedtea6-1.9-shark-debug/openjdk.build/langtools/build/bootstrap/classes [javac] Compiling 244 source files to /home/xerxes/icedtea6-1.9-shark-debug/openjdk.build/langtools/build/bootstrap/classes [javac] # To suppress the following error report, specify this argument [javac] # after -XX: or in .hotspotrc: SuppressErrorAt=/sharkCompiler.cpp:302 [javac] # [javac] # A fatal error has been detected by the Java Runtime Environment: [javac] # [javac] # Internal Error (/home/xerxes/icedtea6-1.9-shark-debug/openjdk-ecj/hotspot/src/share/vm/shark/sharkCompiler.cpp:302), pid=27479, tid=1754794864 [javac] # assert(Thread::current()->is_VM_thread()) failed: must be called by VM thread [javac] # [javac] # JRE version: 6.0_20-b20 [javac] # Java VM: OpenJDK Shark VM (19.0-b09-product mixed mode linux-i386 ) [javac] # Derivative: IcedTea6 1.9.8pre+r2f549e3a4720 [javac] # Distribution: Built on Ubuntu 10.10 (Tue Apr 26 17:13:43 CEST 2011) [javac] # An error report file with more information is saved as: [javac] # /home/xerxes/icedtea6-1.9-shark-debug/openjdk/langtools/hs_err_pid27479.log [javac] # [javac] # If you would like to submit a bug report, please include [javac] # instructions how to reproduce the bug and visit: [javac] # http://icedtea.classpath.org/bugzilla [javac] # [javac] Current thread is 1754794864 [javac] Dumping core ... BUILD FAILED /home/xerxes/icedtea6-1.9-shark-debug/openjdk/langtools/make/build.xml:192: The following error occurred while executing this line: /home/xerxes/icedtea6-1.9-shark-debug/openjdk/langtools/make/build.xml:431: The following error occurred while executing this line: /home/xerxes/icedtea6-1.9-shark-debug/openjdk/langtools/make/build.xml:472: The following error occurred while executing this line: /home/xerxes/icedtea6-1.9-shark-debug/openjdk/langtools/make/build.xml:541: Compile failed; see the compiler error output for details. Total time: 1 minute 3 seconds make[3]: *** [build] Error 1 make[3]: Leaving directory `/home/xerxes/icedtea6-1.9-shark-debug/openjdk/langtools/make' -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 26 08:54:56 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 26 Apr 2011 15:54:56 +0000 Subject: [Bug 559] shark + hs19 crashes in building docs In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=559 --- Comment #12 from Xerxes R?nby 2011-04-26 15:54:56 --- (In reply to comment #11) > (14.20.06) gbenson: the shark changes don't look problematic > (14.20.19) gbenson: and the getclass.ll hasn't changed except for addresses > (14.20.37) gbenson: I think something outside of shark has changed, and shark > needs to mirror it > (14.20.50) gbenson: xranby: have you tried a build with assertions etc? > (14.21.31) xranby: gbenson: no i still have not tested everything :/ > (14.21.39) gbenson: that might show something up > (14.21.46) gbenson: an assertion failure perhaps > I have hitted an assertion early while building hs19 with assertions enabled. I have filed a new bug for this first assertion: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=701 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 26 08:58:23 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 26 Apr 2011 15:58:23 +0000 Subject: [Bug 701] Shark hs19 assert(Thread::current()->is_VM_thread()) failed: must be called by VM thread In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=701 --- Comment #1 from Xerxes R?nby 2011-04-26 15:58:22 --- Created an attachment (id=528) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=528) hs_err_pid27479.log -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Tue Apr 26 09:00:31 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Tue, 26 Apr 2011 16:00:31 +0000 Subject: [Bug 701] Shark hs19 assert(Thread::current()->is_VM_thread()) failed: must be called by VM thread In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=701 --- Comment #2 from Xerxes R?nby 2011-04-26 16:00:31 --- Created an attachment (id=529) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=529) updated contrib/mixtec-hacks.patch to enable assertions using hs19 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From omajid at redhat.com Tue Apr 26 14:15:16 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 26 Apr 2011 17:15:16 -0400 Subject: RFC: drop netx.jar and plugin.jar from bootclasspath Message-ID: <4DB735E4.6000303@redhat.com> Hi, The attached patches drop netx.jar and plugin.jar from hotspot's bootclasspath in icedtea6 and icedtea7. Since the only addition to the bootclasspath is rhino, the patches also move the addition to bootclasspath to the rhino patch. I would like to commit these patches to head(s) only. Since netx.jar and plugin.jar are removed from the bootclasspath, future releases of icedtea6/7 will not work with icedtea-web 1.0, at least as 1.0 currently stands. It should be possible to icedtea-web 1.0 to make it work. Icedtea-web 1.1 onwards should work fine. Any thoughts or concerns? Cheers, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-drop-update-bootclasspath.patch Type: text/x-patch Size: 2343 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110426/bd310638/icedtea6-drop-update-bootclasspath.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea7-rhino-bootclasspath.patch Type: text/x-patch Size: 2557 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110426/bd310638/icedtea7-rhino-bootclasspath.patch From omajid at redhat.com Tue Apr 26 14:31:05 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 26 Apr 2011 17:31:05 -0400 Subject: RFC: drop patches/ssl.patch Message-ID: <4DB73999.5070601@redhat.com> Hi, The attached patch drops patches/ssl.patch from icedtea6. ssl.patch contains no functional changes. From what I can see it casts some classes: TlsMasterSecretParameterSpec is cast to AlgorithmParameterSpec TlsRsaPremasterSecretParameterSpec is cast to AlgorithmParameterSpec The class definitions are: jdk/src/share/classes/sun/security/internal/spec/TlsMasterSecretParameterSpec.java: public class TlsMasterSecretParameterSpec implements AlgorithmParameterSpec jdk/src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java: public class TlsRsaPremasterSecretParameterSpec implements AlgorithmParameterSpec This makes the patch look quite redundant. Should I go ahead and drop the patch? Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-drop-ssl.patch Type: text/x-patch Size: 2582 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110426/c4b02594/icedtea6-drop-ssl.patch From omajid at redhat.com Tue Apr 26 15:42:00 2011 From: omajid at redhat.com (Omair Majid) Date: Tue, 26 Apr 2011 18:42:00 -0400 Subject: IcedTea6 build failed for 92ce3a01d889 In-Reply-To: <4DB1F4D0.2000200@redhat.com> References: <4DB19767.9020102@redhat.com> <4DB1F4D0.2000200@redhat.com> Message-ID: <4DB74A38.7090106@redhat.com> On 04/22/2011 05:36 PM, Omair Majid wrote: > On 04/22/2011 10:57 AM, Omair Majid wrote: > >> >> Meanwhile, should I add back the bytebuffer-compact patch to un-break >> the build? Sorry about the breakage. > > I have reverted the patch. > Updated patch attached. It updates classes under generated/nio/ to use discardMark() instead of clearMark(), and drops the bytebuffer-compact patch which was introducing the new clearMark() method. I was thinking of just updating the contents of generated/nio/*, but Andrew Hughes pointed out on IRC that we dont need stuff under generated to be up-to-date. ChangeLog: 2011-04-26 Omair Majid * Makefile.am (ICEDTEA_PATCHES): Drop bytebuffer-compact.patch * generated/java/nio/DirectByteBuffer.java, * generated/java/nio/DirectCharBufferS.java, * generated/java/nio/DirectCharBufferU.java, * generated/java/nio/DirectDoubleBufferS.java, * generated/java/nio/DirectDoubleBufferU.java, * generated/java/nio/DirectFloatBufferS.java, * generated/java/nio/DirectFloatBufferU.java, * generated/java/nio/DirectIntBufferS.java, * generated/java/nio/DirectIntBufferU.java, * generated/java/nio/DirectLongBufferS.java, * generated/java/nio/DirectLongBufferU.java, * generated/java/nio/DirectShortBufferS.java, * generated/java/nio/DirectShortBufferU.java, * generated/java/nio/HeapByteBuffer.java, * generated/java/nio/HeapCharBuffer.java, * generated/java/nio/HeapDoubleBuffer.java, * generated/java/nio/HeapFloatBuffer.java, * generated/java/nio/HeapIntBuffer.java, * generated/java/nio/HeapLongBuffer.java, * generated/java/nio/HeapShortBuffer.java: Replace all uses of clearMark with discardMark. * patches/bytebuffer-compact.patch: Remove. Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea6-remove-bytebuffer-patch-02.patch Type: text/x-patch Size: 10383 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110426/1d955742/icedtea6-remove-bytebuffer-patch-02.patch From xiaoqiangnk at gmail.com Tue Apr 26 18:32:40 2011 From: xiaoqiangnk at gmail.com (Yongqiang Yang) Date: Wed, 27 Apr 2011 09:32:40 +0800 Subject: merging of Hotspot with MIPS support In-Reply-To: <4DB6813E.4050206@zafena.se> References: <4DB6813E.4050206@zafena.se> Message-ID: On Tue, Apr 26, 2011 at 4:24 PM, Xerxes R?nby wrote: > Hi Yongqiang! > > On 2011-04-25 04:47, Yongqiang Yang wrote: >> >> Hi guys, >> >> We have ported Hotspot client to MIPS compatible processors, and code >> can be got from ?http://icedtea.classpath.org/hg/openjdk6-mips/. > > The MIPS ports looks like it are based on OpenJDK6 and Hotspot hs14, the > same hotspot used in the IcedTea6-1.8 release. > > >> I want to know how to merge the code to Icedtea. ?Is there a site >> which describes the steps we should take and what's the requirements? > > In order to merge the MIPS port with IcedTea6 you will have to update the > MIPS port to be compatible with the same hotspot used by IcedTea6 HEAD. > > The IcedTea6-1.8 release branch uses the same hotspot version hs14 as the > MIPS port so a merge at this point are easy but its too late to go in > because the release branches do not accept new features. > > The IcedTea6-1.9 release uses hotspot version hs17. > The IcedTea6-1.10 release uses hotspot version hs19. > The next IcedTea6-1.11 release are currently based on hs20, HEAD. > > For a merge to happen its required to update the MIPS port to hs20 and merge > it against the current development HEAD at: > http://icedtea.classpath.org/hg/icedtea6 > > You can track when the release branches forked from the IcedTea6 tag list: > http://icedtea.classpath.org/hg/icedtea6/tags > > I suggest you start by first checkout the IcedTea6-1.8 branch-point > http://icedtea.classpath.org/hg/icedtea6/rev/9420faca6468 > and merge at this point. > > Then pull in the IcedTea6-1.9 branch-point merge and fix any issues when > using hs17. > Then pull in the IcedTea6-1.10 branch-point merge and fix any issues when > using hs19. > Then pull in the IcedTea6 developement HEAD, merge and fix any issues when > using hs20. > > When this are done please send in a patch. Thank you very much. I will do as you suggested. Cheers, Yongqiang. > > Cheers > Xerxes > -- Best Wishes Yongqiang Yang From aph at redhat.com Wed Apr 27 01:49:59 2011 From: aph at redhat.com (Andrew Haley) Date: Wed, 27 Apr 2011 09:49:59 +0100 Subject: [RFC][netx]: unsafe write to HashMap In-Reply-To: <1480987931.188008.1302627021361.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1480987931.188008.1302627021361.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4DB7D8B7.4020104@redhat.com> On 12/04/11 17:50, Denis Lila wrote: > Hi Andrew. > > I'm sorry it took so long to answer this. I've been busy > with a few other things. > >> No, this isn't enough. This piece of code: >> >> private URL findBestUrl(Resource resource) { >> 1. DownloadOptions options = downloadOptions.get(resource); >> 2. if (options == null) { >> 3. options = new DownloadOptions(false, false); >> } >> >> may be subject to a race from addResource. Line 1 may retrieve null, >> but that thread may then be interrupted before line 2 can be executed. >> In the meantime, the resource could be added to downloadOptions and >> this thread would still have the old stale value. > > I don't think this is a problem findBestUrl never races with addResource. > It's only called from initializeResource, which isn't called unless > the resource has been already added. > >> It's also odd code in that this new instance is created but not stored >> in the map. So it seems possible that many threads could call this >> method, all get a return value of null and create new instances of >> DownloadOptions. The control flow in this class is not very clear, >> but I presume the null check means that there is a possibility that >> this method can be called before the resource is added in addResource. >> >> I would suggest replacing those three lines with: >> >> DownloadOptions options = downloadOptions.putIfAbsent(resource, new >> DownloadOptions(false,false)); > > I agree that it's odd, but this code has deadlocks in it and it's far > more complex than necessary so a lot of it will be re-written. I would > like to wait until that happens before pushing something like your > suggestion, because it is likely to become unecessary. What harm can putIfAbsent possibly do, though? It's clear and straightforward. Andrew. From bugzilla-daemon at icedtea.classpath.org Wed Apr 27 02:16:16 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 27 Apr 2011 09:16:16 +0000 Subject: [Bug 702] New: Crash when generating openstreetmap maps using mkgmap Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=702 Summary: Crash when generating openstreetmap maps using mkgmap Product: IcedTea Version: 6-1.8.7 Platform: all OS/Version: Linux Status: NEW Severity: critical Priority: P5 Component: IcedTea6 AssignedTo: unassigned at icedtea.classpath.org ReportedBy: d-r at roettsches.de When running the openstreetmap Mkgmap tool, my VM crashed. VM arguments / command line can be seen from the attached error report. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Wed Apr 27 02:16:47 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 27 Apr 2011 09:16:47 +0000 Subject: [Bug 702] Crash when generating openstreetmap maps using mkgmap In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=702 --- Comment #1 from Dominik R?ttsches 2011-04-27 09:16:46 --- Created an attachment (id=530) --> (http://icedtea.classpath.org/bugzilla/attachment.cgi?id=530) Autogenerated Crash Log -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From ahughes at redhat.com Wed Apr 27 05:53:30 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 27 Apr 2011 13:53:30 +0100 Subject: RFC: Forward port icedtea6's debug-dir patch to icedtea7 In-Reply-To: <4DB05FDD.1070509@redhat.com> References: <4DB05FDD.1070509@redhat.com> Message-ID: <20110427125330.GB28246@rivendell.middle-earth.co.uk> On 12:48 Thu 21 Apr , Omair Majid wrote: > Hi, > > The debug-dir patch from icedtea6 needs to be added to icedtea7. Without > this patch, a 'make icedtea-debug' creates a openjdk.build-debug dir > which is essentially empty, but places the build in actually (on my > macine) linux-amd64-debug under the current directory. > > The attached patch is the trivial port. Okay to commit? > > ChangeLog: > 2011-04-21 Omair Majid > > * Makefile.am (ICEDTEA_PATCHES): Add debug-dir.patch > * patches/debug-dir.patch: New file. Forward port from icedtea6. > > Cheers, > Omair No. This needs to go in the IcedTea forest at a minimum, not IcedTea7. Has this not been pushed upstream? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From xerxes at zafena.se Wed Apr 27 06:06:33 2011 From: xerxes at zafena.se (=?ISO-8859-1?Q?Xerxes_R=E5nby?=) Date: Wed, 27 Apr 2011 15:06:33 +0200 Subject: merging of Hotspot with MIPS support In-Reply-To: References: <4DB6813E.4050206@zafena.se> Message-ID: <4DB814D9.1030006@zafena.se> On 2011-04-27 03:32, Yongqiang Yang wrote: > On Tue, Apr 26, 2011 at 4:24 PM, Xerxes R?nby wrote: >> Hi Yongqiang! >> >> On 2011-04-25 04:47, Yongqiang Yang wrote: >>> >>> Hi guys, >>> >>> We have ported Hotspot client to MIPS compatible processors, and code >>> can be got from http://icedtea.classpath.org/hg/openjdk6-mips/. >> >> The MIPS ports looks like it are based on OpenJDK6 and Hotspot hs14, the >> same hotspot used in the IcedTea6-1.8 release. >> >> >>> I want to know how to merge the code to Icedtea. Is there a site >>> which describes the steps we should take and what's the requirements? >> >> In order to merge the MIPS port with IcedTea6 you will have to update the >> MIPS port to be compatible with the same hotspot used by IcedTea6 HEAD. >> >> The IcedTea6-1.8 release branch uses the same hotspot version hs14 as the >> MIPS port so a merge at this point are easy but its too late to go in >> because the release branches do not accept new features. >> >> The IcedTea6-1.9 release uses hotspot version hs17. >> The IcedTea6-1.10 release uses hotspot version hs19. >> The next IcedTea6-1.11 release are currently based on hs20, HEAD. >> >> For a merge to happen its required to update the MIPS port to hs20 and merge >> it against the current development HEAD at: >> http://icedtea.classpath.org/hg/icedtea6 >> >> You can track when the release branches forked from the IcedTea6 tag list: >> http://icedtea.classpath.org/hg/icedtea6/tags >> >> I suggest you start by first checkout the IcedTea6-1.8 branch-point >> http://icedtea.classpath.org/hg/icedtea6/rev/9420faca6468 >> and merge at this point. >> >> Then pull in the IcedTea6-1.9 branch-point merge and fix any issues when >> using hs17. >> Then pull in the IcedTea6-1.10 branch-point merge and fix any issues when >> using hs19. >> Then pull in the IcedTea6 developement HEAD, merge and fix any issues when >> using hs20. >> >> When this are done please send in a patch. > Thank you very much. I will do as you suggested. The IcedTea6 tree are organized a bit differently compared to the upstream openjdk src trees. As you probably have noticed the IcedTea6 tree mostly contain build scrips and patches against the upstream openjdk/hotspot trees. Files that are not available upstream are maintained in the various icedtea6/subdirectorys. I suggest you to create a icedtea6/mips_port subdirectory and inside put all new mips hotspot files in there. Then add mips_port to EXTRA_DIST in the Makefile.am file. This will make a copy of all files inside this mips_port dir to be placed on top of the downloaded openjdk tree during the build. Any mips changes made to the existing upstream openjdk src tree needs to be turned into a patch and places at icedtea6/patches/mips.patch Then add patches/mips.patch to ICEDTEA_PATCHES in the Makefile.am file. To perform a build using icedtea then run: ./autogen.sh mkdir build cd build ../configure make > > Cheers, > Yongqiang. >> >> Cheers >> Xerxes From bugzilla-daemon at icedtea.classpath.org Wed Apr 27 06:35:19 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 27 Apr 2011 13:35:19 +0000 Subject: [Bug 701] Shark hs19 assert(Thread::current()->is_VM_thread()) failed: must be called by VM thread In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=701 --- Comment #3 from Xerxes R?nby 2011-04-27 13:35:19 --- Backtrace: (gdb) bt #0 0x40000832 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x401091a6 in nanosleep () at ../sysdeps/unix/syscall-template.S:82 #2 0x40108fa0 in __sleep (seconds=0) at ../sysdeps/unix/sysv/linux/sleep.c:138 #3 0x405ea07b in os::infinite_sleep () at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/os/linux/vm/os_linux.cpp:3123 #4 0x405e6256 in os::abort (dump_core=true) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/os/linux/vm/os_linux.cpp:1489 #5 0x40707479 in VMError::report_and_die (this=0x6897ffb4) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/utilities/vmError.cpp:898 #6 0x4039d63f in report_vm_error ( file=0x408a2a4c "/home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/shark/sharkCompiler.cpp", line=302, error_msg=0x408a2b80 "assert(Thread::current()->is_VM_thread()) failed", detail_msg=0x408a2b63 "must be called by VM thread") at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/utilities/debug.cpp:176 #7 0x406744b9 in SharkCompiler::free_compiled_method (this=0x822fbe8, code=0x41e4fac0 " \b}hh\244\071 at HO#\b\300\347|\t", ) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/shark/shar---Type to continue, or q to quit--- kCompiler.cpp:302 #8 0x405c9a8a in nmethod::flush (this=0x41e4f9c8) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/code/nmethod.cpp:1379 #9 0x406a732d in NMethodSweeper::process_nmethod (nm=0x41e4f9c8) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/runtime/sweeper.cpp:231 #10 0x406a6fd5 in NMethodSweeper::sweep_code_cache () at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/runtime/sweeper.cpp:171 #11 0x406a6e18 in NMethodSweeper::possibly_sweep () at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/runtime/sweeper.cpp:129 #12 0x4033fc0c in CompileQueue::get (this=0x6881bff8) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/compiler/compileBroker.cpp:464 #13 0x403421b7 in CompileBroker::compiler_thread_loop () at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/compiler/compileBroker.cpp:1376 #14 0x406ca823 in compiler_thread_entry (thread=0x6881c430, __the_thread__=0x6881c430) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/runtime/thread.cpp:2816 ---Type to continue, or q to quit--- #15 0x406c6899 in JavaThread::thread_main_inner (this=0x6881c430) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/runtime/thread.cpp:1428 #16 0x406c6797 in JavaThread::run (this=0x6881c430) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/share/vm/runtime/thread.cpp:1412 #17 0x405e4d3c in java_start (thread=0x6881c430) at /home/xerxes/icedtea6-1.9/build/openjdk-ecj/hotspot/src/os/linux/vm/os_linux.cpp:799 #18 0x40050cc9 in start_thread (arg=0x68980b70) at pthread_create.c:304 #19 0x4014069e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Wed Apr 27 07:05:13 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 27 Apr 2011 14:05:13 +0000 Subject: [Bug 700] Error detected by the Java Runtime Environment in libreoffice In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=700 --- Comment #3 from Kara 2011-04-27 14:05:13 --- (In reply to comment #2) > Hello Kara, > > I took a quick look at the log you have posted, this is an issue with one of > the library that openoffice is using: libsvllx.so > A segmentation fault occurred and caused the crash. > > I will close this as invalid, since it is not a crash caused by java. > Ah, ok, sounds good. Thanks! -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From bugzilla-daemon at icedtea.classpath.org Wed Apr 27 07:10:00 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 27 Apr 2011 14:10:00 +0000 Subject: [Bug 701] Shark hs19 assert(Thread::current()->is_VM_thread()) failed: must be called by VM thread In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=701 --- Comment #4 from Xerxes R?nby 2011-04-27 14:10:00 --- "Since the sweeper no longer runs at a safepoint the compiled method unload logic doesn't always run at a safepoint so we need a new synchronous notification path that's equivalent to the compiled_method_load logic." http://cr.openjdk.java.net/~never/6956931/ We have to update shark to work in spirit of this changeset: http://hg.openjdk.java.net/jdk7/hotspot-comp/hotspot/rev/852d0157c696 ... A start are to replace the assert assert(Thread::current()->is_VM_thread(), "must be called by VM thread"); with this assert(JavaThread::current()->thread_state() == _thread_in_vm, "must run in vm mode"); this will make the assert work but the code still thinks it are running on a safepoint and this needs to be fixed as well. -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From omajid at redhat.com Wed Apr 27 07:17:29 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 27 Apr 2011 10:17:29 -0400 Subject: RFC: Forward port icedtea6's debug-dir patch to icedtea7 In-Reply-To: <20110427125330.GB28246@rivendell.middle-earth.co.uk> References: <4DB05FDD.1070509@redhat.com> <20110427125330.GB28246@rivendell.middle-earth.co.uk> Message-ID: <4DB82579.9080205@redhat.com> On 04/27/2011 08:53 AM, Dr Andrew John Hughes wrote: > On 12:48 Thu 21 Apr , Omair Majid wrote: >> Hi, >> >> The debug-dir patch from icedtea6 needs to be added to icedtea7. Without >> this patch, a 'make icedtea-debug' creates a openjdk.build-debug dir >> which is essentially empty, but places the build in actually (on my >> macine) linux-amd64-debug under the current directory. >> >> The attached patch is the trivial port. Okay to commit? >> >> ChangeLog: >> 2011-04-21 Omair Majid >> >> * Makefile.am (ICEDTEA_PATCHES): Add debug-dir.patch >> * patches/debug-dir.patch: New file. Forward port from icedtea6. >> >> Cheers, >> Omair > > No. This needs to go in the IcedTea forest at a minimum, not IcedTea7. > > Has this not been pushed upstream? I think this was originally a backport from upstream. But since then, upstream has reverted the change: http://hg.openjdk.java.net/jdk7/tl/diff/47f6b7db1882/Makefile So I am not sure if they will be willing to accept this patch. Perhaps if it was special cased for non-windows platforms, they might be more forthcoming. Thanks, Omair From bugzilla-daemon at icedtea.classpath.org Wed Apr 27 07:21:28 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 27 Apr 2011 14:21:28 +0000 Subject: [Bug 687] BasicService.getCodeBase() returns null for IcedTea6 1.9.7 + OSGI In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=687 Omair Majid changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED --- Comment #3 from Omair Majid 2011-04-27 14:21:28 --- Fix committed: http://icedtea.classpath.org/hg/icedtea-web/rev/6528c988d538 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. From ahughes at redhat.com Wed Apr 27 07:47:56 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 27 Apr 2011 15:47:56 +0100 Subject: RFC: drop netx.jar and plugin.jar from bootclasspath In-Reply-To: <4DB735E4.6000303@redhat.com> References: <4DB735E4.6000303@redhat.com> Message-ID: <20110427144756.GD28246@rivendell.middle-earth.co.uk> On 17:15 Tue 26 Apr , Omair Majid wrote: > Hi, > > The attached patches drop netx.jar and plugin.jar from hotspot's > bootclasspath in icedtea6 and icedtea7. Since the only addition to the > bootclasspath is rhino, the patches also move the addition to > bootclasspath to the rhino patch. I would like to commit these patches > to head(s) only. > > Since netx.jar and plugin.jar are removed from the bootclasspath, future > releases of icedtea6/7 will not work with icedtea-web 1.0, at least as > 1.0 currently stands. It should be possible to icedtea-web 1.0 to make > it work. Icedtea-web 1.1 onwards should work fine. > > Any thoughts or concerns? > > Cheers, > Omair I don't see a reason to do this so soon with 1.1 not even out yet. Let's wait until after the next IcedTea6/7 releases (1.14 & 1.11) and decide then. It's not a big enough issue to go breaking older versions of IcedTea-Web. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at redhat.com Wed Apr 27 07:49:43 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 27 Apr 2011 10:49:43 -0400 Subject: RFC: Mark stack as non-executable Message-ID: <4DB82D07.8030902@redhat.com> Hi, This patch for the icedtea7 forest (hotspot repo), ported from IcedTea6, marks libjvm.so's stack as non-executable. This patch should really be pushed upstream, but it was originally written by Kees Cook who is not on the list of SCA signatories [1]. Any comments? Thanks, Omair [1] http://sca.java.net/CA_signatories.htm -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea7-make-stack-non-executable.patch Type: text/x-patch Size: 661 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110427/2c8b5c7f/icedtea7-make-stack-non-executable.patch From ahughes at redhat.com Wed Apr 27 07:50:07 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Wed, 27 Apr 2011 15:50:07 +0100 Subject: RFC: drop patches/ssl.patch In-Reply-To: <4DB73999.5070601@redhat.com> References: <4DB73999.5070601@redhat.com> Message-ID: <20110427145007.GE28246@rivendell.middle-earth.co.uk> On 17:31 Tue 26 Apr , Omair Majid wrote: > Hi, > > The attached patch drops patches/ssl.patch from icedtea6. ssl.patch > contains no functional changes. From what I can see it casts some classes: > > TlsMasterSecretParameterSpec is cast to AlgorithmParameterSpec > TlsRsaPremasterSecretParameterSpec is cast to AlgorithmParameterSpec > > The class definitions are: > > jdk/src/share/classes/sun/security/internal/spec/TlsMasterSecretParameterSpec.java: > > public class TlsMasterSecretParameterSpec implements AlgorithmParameterSpec > > jdk/src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java: > > public class TlsRsaPremasterSecretParameterSpec implements > AlgorithmParameterSpec > > This makes the patch look quite redundant. Should I go ahead and drop > the patch? > > Thanks, > Omair Have you tested this with a full build, i.e. not with --disable-bootstrap which I know is how you tend to build? I've already dropped it from 7. I couldn't find any record of why it was added (pre-1.0 if I recall correctly) and I think it was probably down to when we were using GNU Crypto to provide cryptography, before Sun released theirs as part of OpenJDK. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at redhat.com Wed Apr 27 08:58:37 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 27 Apr 2011 11:58:37 -0400 (EDT) Subject: [RFC][icedtea6]: backports - AA drawing to screen performance In-Reply-To: <273312509.1020520.1303919581672.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <455002700.1020646.1303919917431.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi I would like to backport these two changesets: http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b8f91ea2fb33 http://hg.openjdk.java.net/jdk7/2d/jdk/rev/15435c60c751 The first one refactors a bit of stuff, and puts an abstract method in SunGraphicsEnvironment, which is needed by the second patch. The second changeset (which is the whole point for this) drastically speeds up certain screen rendering operations. Unfortunately, it modifies a couple of files that are also modified by the xrender-01.patch, so that had to be changed to make get both patches apply. ChangeLog: 2011-04-27 Denis Lila * Makefile.am: Apply patches. * NEWS: Update with backports. * patches/openjdk/6748082-isDisplayLocal.patch: New patch. * patches/openjdk/6708580-exa_slow.patch: New patch. Speeds up certain rendering operations. * patches/openjdk/6307603-xrender-01.patch: Make it apply when the previous patch has been applied before it. How does it look? (I tested it of course. It built, and it does give a huge speedup) Regards, Denis. From dlila at redhat.com Wed Apr 27 09:04:38 2011 From: dlila at redhat.com (Denis Lila) Date: Wed, 27 Apr 2011 12:04:38 -0400 (EDT) Subject: [RFC][icedtea6]: backports - AA drawing to screen performance In-Reply-To: <455002700.1020646.1303919917431.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <2074323378.1020764.1303920278946.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Hi I would like to backport these two changesets: > > http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b8f91ea2fb33 > http://hg.openjdk.java.net/jdk7/2d/jdk/rev/15435c60c751 > > The first one refactors a bit of stuff, and puts an abstract > method in SunGraphicsEnvironment, which is needed by the > second patch. The second changeset (which is the whole point > for this) drastically speeds up certain screen rendering operations. > > Unfortunately, it modifies a couple of files that are also modified > by the xrender-01.patch, so that had to be changed to make get both > patches apply. > > ChangeLog: > 2011-04-27 Denis Lila > > * Makefile.am: Apply patches. > * NEWS: Update with backports. > * patches/openjdk/6748082-isDisplayLocal.patch: New patch. > * patches/openjdk/6708580-exa_slow.patch: New patch. Speeds > up certain rendering operations. > * patches/openjdk/6307603-xrender-01.patch: Make it apply when > the previous patch has been applied before it. > > > How does it look? (I tested it of course. It built, and it does give > a huge speedup) I'm sorry, I forgot to attach the patch. ----- Original Message ----- > > Regards, > Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: aa-screen-perf.patch Type: text/x-patch Size: 13078 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110427/9b144001/aa-screen-perf.patch From bugzilla-daemon at icedtea.classpath.org Wed Apr 27 10:44:26 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Wed, 27 Apr 2011 17:44:26 +0000 Subject: [Bug 683] jdk crash In-Reply-To: References: Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=683 Xerxes R?nby changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |xerxes at zafena.se Severity|major |normal --- Comment #1 from Xerxes R?nby 2011-04-27 17:44:26 --- Hi! When looking through the two jvm error logs in your compressed 7zip i noticed two different errors: error 1: # Internal Error (nmethod.cpp:1847), pid=28897, tid=139899151791888 # Error: guarantee(cont_offset != 0,"unhandled implicit exception in compiled code") # # JRE version: 6.0_17-b17 # Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 ) # Derivative: IcedTea6 1.7.10 # Distribution: Custom build (Mon Feb 14 13:03:32 EST 2011) This error looks like a duplicate of PR536 http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=536 error 2: # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00007f87f449417e, pid=18384, tid=140221754496784 # # JRE version: 6.0_17-b17 # Java VM: OpenJDK 64-Bit Server VM (14.0-b16 mixed mode linux-amd64 ) # Derivative: IcedTea6 1.7.10 # Distribution: Custom build (Mon Feb 14 13:03:32 EST 2011) # Problematic frame: # V [libjvm.so+0x34317e] Im not sure about this one... we need a gdb backtrace to be certain whats causing this segmentation fault. I have been trying to reproduce your bug by using OpenJDK Runtime Environment (IcedTea6 1.10.1) (6b22-1.10.1-0ubuntu1) OpenJDK Server VM (build 20.0-b11, mixed mode) and the following testcase: wget http://www.hazelcast.com/files/hazelcast-1.9.2.3.zip unzip hazelcast-1.9.2.3 cd cd hazelcast-1.9.2.3/bin sh test.sh But I am unable to reproduce it on my machine. Is possible that these both bugs have been fixed when using a newer hotspot version. Can you check if you can still reproduce this bug using IcedTea6 1.9.x that uses a newer hotspot hs17/hs19? Can you check if you can still reproduce this bug using IcedTea6 1.10.x that uses a newer hotspot hs19/hs20? Thanks -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From omajid at redhat.com Wed Apr 27 14:42:07 2011 From: omajid at redhat.com (Omair Majid) Date: Wed, 27 Apr 2011 17:42:07 -0400 Subject: RFC: drop patches/ssl.patch In-Reply-To: <20110427145007.GE28246@rivendell.middle-earth.co.uk> References: <4DB73999.5070601@redhat.com> <20110427145007.GE28246@rivendell.middle-earth.co.uk> Message-ID: <4DB88DAF.6030505@redhat.com> On 04/27/2011 10:50 AM, Dr Andrew John Hughes wrote: > On 17:31 Tue 26 Apr , Omair Majid wrote: >> > Hi, >> > >> > The attached patch drops patches/ssl.patch from icedtea6. ssl.patch >> > contains no functional changes. From what I can see it casts some classes: >> > >> > TlsMasterSecretParameterSpec is cast to AlgorithmParameterSpec >> > TlsRsaPremasterSecretParameterSpec is cast to AlgorithmParameterSpec >> > >> > The class definitions are: >> > >> > jdk/src/share/classes/sun/security/internal/spec/TlsMasterSecretParameterSpec.java: >> > >> > public class TlsMasterSecretParameterSpec implements AlgorithmParameterSpec >> > >> > jdk/src/share/classes/sun/security/internal/spec/TlsRsaPremasterSecretParameterSpec.java: >> > >> > public class TlsRsaPremasterSecretParameterSpec implements >> > AlgorithmParameterSpec >> > >> > This makes the patch look quite redundant. Should I go ahead and drop >> > the patch? >> > >> > Thanks, >> > Omair > Have you tested this with a full build, i.e. not with --disable-bootstrap which I know is > how you tend to build? > Yes. In fact, (after the screw-up last week) I am now building icedtea{6,7} using just ./configure. I will build it again before I push. > I've already dropped it from 7. Yes, I saw that it was missing. I was trying to find out if I should add it to icedtea7 or drop it even from icedtea6. > I couldn't find any record of why it was added (pre-1.0 > if I recall correctly) and I think it was probably down to when we were using GNU Crypto > to provide cryptography, before Sun released theirs as part of OpenJDK. The icedtea6 changeset a51ee3008713 indicates that it was added when openjdk6 started providing crypto. But you are more familiar with the history than I am. Cheers, Omair From fweimer at bfk.de Thu Apr 28 01:28:52 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 28 Apr 2011 08:28:52 +0000 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <20110420224731.GZ29985@rivendell.middle-earth.co.uk> (Andrew John Hughes's message of "Wed\, 20 Apr 2011 23\:47\:31 +0100") References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DADA957.8050004@ubuntu.com> <4DAEA8BC.2030801@oracle.com> <4DAEAC8C.8060901@ubuntu.com> <4DAEC236.2090706@oracle.com> <20110420224731.GZ29985@rivendell.middle-earth.co.uk> Message-ID: <82iptybwzf.fsf@mid.bfk.de> * Andrew John Hughes: > I would actually like to know this too. In what situations is > knowing the distro helpful? For distro-specific builds, the package version number would give you the information (e.g., recent Debian builds have "~squeeze" or "~lenny" in their version numbers), and it is included in crash dumps. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From mvyskocil at suse.cz Thu Apr 28 02:51:50 2011 From: mvyskocil at suse.cz (Michal Vyskocil) Date: Thu, 28 Apr 2011 11:51:50 +0200 Subject: Improving the Identication of Linux Distributions when Dumping In-Reply-To: <4DA01811.5010906@oracle.com> References: <67857eba-9c58-45af-97f8-fef3b2d65b9b@default> <4DA01811.5010906@oracle.com> Message-ID: <20110428095150.GD27380@zelva.suse.cz> On Sat, Apr 09, 2011 at 12:25:53PM +0400, Dmitry Samersoff wrote: > Robert, > > I'm second with Andrew: > > > I really don't see why the current solution is such a problem. This > > sounds like it's just going to make the output messy. > > because > (1) we must not call external program during crash reporting > (2) Information from /etc/*-releases doesn't reflect upgrades, > especially if it's point upgrade of a particular package so we still > need to collect libraries from client computer to open a core. > > So I would prefer to see: > if exist [one of known to be useful /etc/*-releases ] : > print distro name > else: > print "Unknown" You might consider a support for /etc/os-release, which will appear in a next Fedora and then in all other systems with systemd like openSUSE or Debian. And I think this will be something like a best-practice even for systems don't want to use systemd. [1] http://0pointer.de/public/systemd-man/os-release.html Regards Michal Vyskocil From ahughes at redhat.com Thu Apr 28 05:05:20 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 28 Apr 2011 13:05:20 +0100 Subject: RFC: Mark stack as non-executable In-Reply-To: <4DB82D07.8030902@redhat.com> References: <4DB82D07.8030902@redhat.com> Message-ID: <20110428120520.GJ28246@rivendell.middle-earth.co.uk> On 10:49 Wed 27 Apr , Omair Majid wrote: > Hi, > > This patch for the icedtea7 forest (hotspot repo), ported from IcedTea6, > marks libjvm.so's stack as non-executable. > > This patch should really be pushed upstream, but it was originally > written by Kees Cook who is not on the list of SCA signatories [1]. > > Any comments? > > Thanks, > Omair > > [1] http://sca.java.net/CA_signatories.htm I thought there was some effort to get it upstream. Have you checked the archives? Ok for the IcedTea7 forest: http://hg.openjdk.java.net/icedtea/jdk7/hotspot > diff -r ef8632d52263 src/os_cpu/linux_x86/vm/linux_x86_32.s > --- a/src/os_cpu/linux_x86/vm/linux_x86_32.s Wed Apr 20 04:38:06 2011 +0100 > +++ b/src/os_cpu/linux_x86/vm/linux_x86_32.s Wed Apr 27 10:46:17 2011 -0400 > @@ -666,3 +666,4 @@ > fistpll (%eax) > ret > > +.section .note.GNU-stack, "", @progbits > diff -r ef8632d52263 src/os_cpu/linux_x86/vm/linux_x86_64.s > --- a/src/os_cpu/linux_x86/vm/linux_x86_64.s Wed Apr 20 04:38:06 2011 +0100 > +++ b/src/os_cpu/linux_x86/vm/linux_x86_64.s Wed Apr 27 10:46:17 2011 -0400 > @@ -400,3 +400,4 @@ > addq $4,%rdx > jg 4b > ret > +.section .note.GNU-stack, "", @progbits -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 28 05:18:03 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 28 Apr 2011 13:18:03 +0100 Subject: [RFC][icedtea6]: backports - AA drawing to screen performance In-Reply-To: <2074323378.1020764.1303920278946.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <455002700.1020646.1303919917431.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <2074323378.1020764.1303920278946.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110428121803.GM28246@rivendell.middle-earth.co.uk> On 12:04 Wed 27 Apr , Denis Lila wrote: > > Hi I would like to backport these two changesets: > > > > http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b8f91ea2fb33 > > http://hg.openjdk.java.net/jdk7/2d/jdk/rev/15435c60c751 > > > > The first one refactors a bit of stuff, and puts an abstract > > method in SunGraphicsEnvironment, which is needed by the > > second patch. The second changeset (which is the whole point > > for this) drastically speeds up certain screen rendering operations. > > > > Unfortunately, it modifies a couple of files that are also modified > > by the xrender-01.patch, so that had to be changed to make get both > > patches apply. > > > > ChangeLog: > > 2011-04-27 Denis Lila > > > > * Makefile.am: Apply patches. > > * NEWS: Update with backports. > > * patches/openjdk/6748082-isDisplayLocal.patch: New patch. > > * patches/openjdk/6708580-exa_slow.patch: New patch. Speeds > > up certain rendering operations. > > * patches/openjdk/6307603-xrender-01.patch: Make it apply when > > the previous patch has been applied before it. > > > > > > How does it look? (I tested it of course. It built, and it does give > > a huge speedup) > > I'm sorry, I forgot to attach the patch. > > ----- Original Message ----- > > > > > Regards, > > Denis. Looks good. Please commit to HEAD. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at icedtea.classpath.org Thu Apr 28 05:32:15 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Thu, 28 Apr 2011 12:32:15 +0000 Subject: /hg/icedtea6: Speed up AA rendering to screen. Message-ID: changeset ad45dd8bcf45 in /hg/icedtea6 details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=ad45dd8bcf45 author: Denis Lila date: Thu Apr 28 08:36:21 2011 -0400 Speed up AA rendering to screen. diffstat: ChangeLog | 10 ++ Makefile.am | 2 + NEWS | 2 + patches/openjdk/6307603-xrender-01.patch | 6 +- patches/openjdk/6708580-exa_slow.patch | 99 ++++++++++++++++++++++++ patches/openjdk/6748082-isDisplayLocal.patch | 111 +++++++++++++++++++++++++++ 6 files changed, 228 insertions(+), 2 deletions(-) diffs (310 lines): diff -r bc0a045bf271 -r ad45dd8bcf45 ChangeLog --- a/ChangeLog Fri Apr 22 17:35:11 2011 -0400 +++ b/ChangeLog Thu Apr 28 08:36:21 2011 -0400 @@ -1,3 +1,13 @@ +2011-04-28 Denis Lila + + * Makefile.am: Apply patches. + * NEWS: Update with backports. + * patches/openjdk/6748082-isDisplayLocal.patch: New patch. + * patches/openjdk/6708580-exa_slow.patch: New patch. Speeds + up certain rendering operations. + * patches/openjdk/6307603-xrender-01.patch: Make it apply when + the previous patch has been applied before it. + 2011-04-22 Omair Majid Revert previous patch. diff -r bc0a045bf271 -r ad45dd8bcf45 Makefile.am --- a/Makefile.am Fri Apr 22 17:35:11 2011 -0400 +++ b/Makefile.am Thu Apr 28 08:36:21 2011 -0400 @@ -204,6 +204,7 @@ patches/openjdk/6682046-shape_calculation.patch \ patches/openjdk/6797195-hw_lw_mixing.patch \ patches/openjdk/6725214-direct3d-01.patch \ + patches/openjdk/6748082-isDisplayLocal.patch \ patches/openjdk/6633275-shaped_translucent_windows.patch \ patches/openjdk/6791612-opengl-jni-fix.patch \ patches/openjdk/6755274-glgetstring-crash.patch \ @@ -310,6 +311,7 @@ patches/g344659-sparc_fix.patch \ patches/openjdk/6728834-blurred-lcd-aa-text.patch \ patches/openjdk/6749060-bad-lcd-aa-non-opaque-dest.patch \ + patches/openjdk/6708580-exa_slow.patch \ patches/openjdk/6896068-sg2d.patch \ patches/pr633-no_javaws_man_page.patch \ patches/pr586-include_all_srcs.patch \ diff -r bc0a045bf271 -r ad45dd8bcf45 NEWS --- a/NEWS Fri Apr 22 17:35:11 2011 -0400 +++ b/NEWS Thu Apr 28 08:36:21 2011 -0400 @@ -18,6 +18,8 @@ - S6768387, PR670: REGRESSION: JTable no longer serializable - Add missing privileged block around access to the sun.awt.nativedebug property. - S7032388, PR682: Make HotSpot work on machines without cmov instruction again + - S6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal + - S6708580: Java applications slow when EXA enabled * Bug fixes - PR637: make check should exit with an error code if any regression test failed. - G356743: Support libpng 1.5. diff -r bc0a045bf271 -r ad45dd8bcf45 patches/openjdk/6307603-xrender-01.patch --- a/patches/openjdk/6307603-xrender-01.patch Fri Apr 22 17:35:11 2011 -0400 +++ b/patches/openjdk/6307603-xrender-01.patch Thu Apr 28 08:36:21 2011 -0400 @@ -9,12 +9,13 @@ #Java_sun_awt_motif_MEmbedCanvasPeer_initXEmbedServer; #Java_sun_awt_motif_MEmbedCanvasPeer_destroyXEmbedServer; #Java_sun_awt_motif_MEmbedCanvasPeer_isXEmbedActive; -@@ -406,17 +407,52 @@ +@@ -406,18 +407,53 @@ Java_sun_java2d_x11_X11SurfaceData_initIDs; Java_sun_java2d_x11_X11SurfaceData_initOps; Java_sun_java2d_x11_X11SurfaceData_initSurface; - Java_sun_java2d_x11_X11SurfaceData_isDrawableValid; Java_sun_java2d_x11_X11SurfaceData_isDgaAvailable; + Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable; - Java_sun_java2d_x11_X11SurfaceData_setInvalid; - Java_sun_java2d_x11_X11SurfaceData_flushNativeSurface; - Java_sun_java2d_x11_X11SurfaceData_XCreateGC; @@ -178,7 +179,7 @@ Java_sun_awt_X11GraphicsEnvironment_checkShmExt; Java_sun_awt_X11GraphicsEnvironment_getNumScreens; Java_sun_awt_X11GraphicsEnvironment_getDefaultScreenNum; -@@ -337,20 +338,51 @@ +@@ -337,21 +338,52 @@ Java_sun_java2d_x11_X11Renderer_XFillRect; Java_sun_java2d_x11_X11Renderer_XFillRoundRect; Java_sun_java2d_x11_X11Renderer_devCopyArea; @@ -186,6 +187,7 @@ Java_sun_java2d_x11_X11SurfaceData_initIDs; - Java_sun_java2d_x11_X11SurfaceData_isDrawableValid; Java_sun_java2d_x11_X11SurfaceData_isDgaAvailable; + Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable; - Java_sun_java2d_x11_X11SurfaceData_initOps; Java_sun_java2d_x11_X11SurfaceData_initSurface; - Java_sun_java2d_x11_X11SurfaceData_flushNativeSurface; diff -r bc0a045bf271 -r ad45dd8bcf45 patches/openjdk/6708580-exa_slow.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/openjdk/6708580-exa_slow.patch Thu Apr 28 08:36:21 2011 -0400 @@ -0,0 +1,103 @@ +# HG changeset patch +# User tdv +# Date 1228418486 28800 +# Node ID 15435c60c751bc39af2fc6b3a30744c6713db1de +# Parent c8eea39734e85b50977434a5b37b3eb8ac8c0a59 +6708580: Java applications slow when EXA enabled +Reviewed-by: prr, tdv +Contributed-by: ceisserer + +diff -r c8eea39734e8 -r 15435c60c751 make/sun/awt/mapfile-mawt-vers +--- openjdk.orig/jdk/make/sun/awt/mapfile-mawt-vers Thu Dec 04 10:05:36 2008 -0800 ++++ openjdk/jdk/make/sun/awt/mapfile-mawt-vers Thu Dec 04 11:21:26 2008 -0800 +@@ -407,6 +407,7 @@ + Java_sun_java2d_x11_X11SurfaceData_initSurface; + Java_sun_java2d_x11_X11SurfaceData_isDrawableValid; + Java_sun_java2d_x11_X11SurfaceData_isDgaAvailable; ++ Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable; + Java_sun_java2d_x11_X11SurfaceData_setInvalid; + Java_sun_java2d_x11_X11SurfaceData_flushNativeSurface; + Java_sun_java2d_x11_X11SurfaceData_XCreateGC; +diff -r c8eea39734e8 -r 15435c60c751 make/sun/xawt/mapfile-vers +--- openjdk.orig/jdk/make/sun/xawt/mapfile-vers Thu Dec 04 10:05:36 2008 -0800 ++++ openjdk/jdk/make/sun/xawt/mapfile-vers Thu Dec 04 11:21:26 2008 -0800 +@@ -337,6 +337,7 @@ + Java_sun_java2d_x11_X11SurfaceData_initIDs; + Java_sun_java2d_x11_X11SurfaceData_isDrawableValid; + Java_sun_java2d_x11_X11SurfaceData_isDgaAvailable; ++ Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable; + Java_sun_java2d_x11_X11SurfaceData_initOps; + Java_sun_java2d_x11_X11SurfaceData_initSurface; + Java_sun_java2d_x11_X11SurfaceData_flushNativeSurface; +diff -r c8eea39734e8 -r 15435c60c751 src/solaris/classes/sun/java2d/x11/X11SurfaceData.java +--- openjdk.orig/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java Thu Dec 04 10:05:36 2008 -0800 ++++ openjdk/jdk/src/solaris/classes/sun/java2d/x11/X11SurfaceData.java Thu Dec 04 11:21:26 2008 -0800 +@@ -50,6 +50,7 @@ + import sun.font.X11TextRenderer; + import sun.java2d.InvalidPipeException; + import sun.java2d.SunGraphics2D; ++import sun.java2d.SunGraphicsEnvironment; + import sun.java2d.SurfaceData; + import sun.java2d.SurfaceDataProxy; + import sun.java2d.loops.SurfaceType; +@@ -240,6 +241,11 @@ + */ + public static native boolean isDgaAvailable(); + ++ /** ++ * Returns true if shared memory pixmaps are available ++ */ ++ private static native boolean isShmPMAvailable(); ++ + public static boolean isAccelerationEnabled() { + if (accelerationEnabled == null) { + +@@ -253,8 +259,17 @@ + // true iff prop==true, false otherwise + accelerationEnabled = Boolean.valueOf(prop); + } else { +- // use pixmaps if there is no dga, no matter local or remote +- accelerationEnabled = Boolean.valueOf(!isDgaAvailable()); ++ boolean isDisplayLocal = false; ++ GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); ++ if (ge instanceof SunGraphicsEnvironment) { ++ isDisplayLocal = ((SunGraphicsEnvironment) ge).isDisplayLocal(); ++ } ++ ++ // EXA based drivers tend to place pixmaps in VRAM, slowing down readbacks. ++ // Don't use pixmaps if dga is available, ++ // or we are local and shared memory Pixmaps are not available. ++ accelerationEnabled = ++ !(isDgaAvailable() || (isDisplayLocal && !isShmPMAvailable())); + } + } + } +diff -r c8eea39734e8 -r 15435c60c751 src/solaris/native/sun/java2d/x11/X11SurfaceData.c +--- openjdk.orig/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c Thu Dec 04 10:05:36 2008 -0800 ++++ openjdk/jdk/src/solaris/native/sun/java2d/x11/X11SurfaceData.c Thu Dec 04 11:21:26 2008 -0800 +@@ -208,6 +208,23 @@ + #endif /* HEADLESS */ + } + ++ ++/* ++ * Class: sun_java2d_x11_X11SurfaceData ++ * Method: isShmPMAvailable ++ * Signature: ()Z ++ */ ++JNIEXPORT jboolean JNICALL ++Java_sun_java2d_x11_X11SurfaceData_isShmPMAvailable(JNIEnv *env, jobject this) ++{ ++#if defined(HEADLESS) || !defined(MITSHM) ++ return JNI_FALSE; ++#else ++ return useMitShmPixmaps; ++#endif /* HEADLESS, MITSHM */ ++} ++ ++ + /* + * Class: sun_java2d_x11_X11SurfaceData + * Method: initOps +exporting patch: + diff -r bc0a045bf271 -r ad45dd8bcf45 patches/openjdk/6748082-isDisplayLocal.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/openjdk/6748082-isDisplayLocal.patch Thu Apr 28 08:36:21 2011 -0400 @@ -0,0 +1,116 @@ +# HG changeset patch +# User tdv +# Date 1221256905 25200 +# Node ID b8f91ea2fb33cdbbc177ab1f68170ce7966b5d7b +# Parent cd88b4ad7f258f023f12ebcc3b5a01a826e9392d +6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal +Reviewed-by: prr, tdv +Contributed-by: rkennke at kennke.org + +diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/share/classes/sun/java2d/SunGraphicsEnvironment.java +--- openjdk.orig/jdk/src/share/classes/sun/java2d/SunGraphicsEnvironment.java Thu Aug 28 11:27:14 2008 -0700 ++++ openjdk/jdk/src/share/classes/sun/java2d/SunGraphicsEnvironment.java Fri Sep 12 15:01:45 2008 -0700 +@@ -1272,6 +1272,13 @@ + displayChanger.notifyPaletteChanged(); + } + ++ /** ++ * Returns true when the display is local, false for remote displays. ++ * ++ * @return true when the display is local, false for remote displays ++ */ ++ public abstract boolean isDisplayLocal(); ++ + /* + * ----DISPLAY CHANGE SUPPORT---- + */ +diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/share/classes/sun/swing/SwingUtilities2.java +--- openjdk.orig/jdk/src/share/classes/sun/swing/SwingUtilities2.java Thu Aug 28 11:27:14 2008 -0700 ++++ openjdk/jdk/src/share/classes/sun/swing/SwingUtilities2.java Fri Sep 12 15:01:45 2008 -0700 +@@ -55,6 +55,7 @@ + import java.util.*; + import sun.font.FontDesignMetrics; + import sun.font.FontManager; ++import sun.java2d.SunGraphicsEnvironment; + + import java.util.concurrent.Callable; + import java.util.concurrent.Future; +@@ -1482,22 +1483,14 @@ + * appear capable of performing gamma correction needed for LCD text. + */ + public static boolean isLocalDisplay() { +- try { +- // On Windows just return true. Permission to read os.name +- // is granted to all code but wrapped in try to be safe. +- if (OSInfo.getOSType() == OSInfo.OSType.WINDOWS) { +- return true; +- } +- // Else probably Solaris or Linux in which case may be remote X11 +- Class x11Class = Class.forName("sun.awt.X11GraphicsEnvironment"); +- Method isDisplayLocalMethod = x11Class.getMethod( +- "isDisplayLocal", new Class[0]); +- return (Boolean)isDisplayLocalMethod.invoke(null, (Object[])null); +- } catch (Throwable t) { ++ boolean isLocal; ++ GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment(); ++ if (ge instanceof SunGraphicsEnvironment) { ++ isLocal = ((SunGraphicsEnvironment) ge).isDisplayLocal(); ++ } else { ++ isLocal = true; + } +- // If we get here we're most likely being run on some other O/S +- // or we didn't properly detect Windows. +- return true; ++ return isLocal; + } + + /** +diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/solaris/classes/sun/awt/X11GraphicsEnvironment.java +--- openjdk.orig/jdk/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Thu Aug 28 11:27:14 2008 -0700 ++++ openjdk/jdk/src/solaris/classes/sun/awt/X11GraphicsEnvironment.java Fri Sep 12 15:01:45 2008 -0700 +@@ -209,7 +209,7 @@ + private static native int checkShmExt(); + + private static native String getDisplayString(); +- private static Boolean isDisplayLocal; ++ private Boolean isDisplayLocal; + + /** + * This should only be called from the static initializer, so no need for +@@ -234,7 +234,8 @@ + return getScreenDevices()[getDefaultScreenNum()]; + } + +- public static boolean isDisplayLocal() { ++ @Override ++ public boolean isDisplayLocal() { + if (isDisplayLocal == null) { + SunToolkit.awtLock(); + try { +diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/solaris/native/sun/awt/fontpath.c +--- openjdk.orig/jdk/src/solaris/native/sun/awt/fontpath.c Thu Aug 28 11:27:14 2008 -0700 ++++ openjdk/jdk/src/solaris/native/sun/awt/fontpath.c Fri Sep 12 15:01:45 2008 -0700 +@@ -156,7 +156,7 @@ + + isLocal = JNU_CallStaticMethodByName(env, NULL, + "sun/awt/X11GraphicsEnvironment", +- "isDisplayLocal", ++ "_isDisplayLocal", + "()Z").z; + isLocalSet = True; + return isLocal; +diff -r cd88b4ad7f25 -r b8f91ea2fb33 src/windows/classes/sun/awt/Win32GraphicsEnvironment.java +--- openjdk.orig/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Thu Aug 28 11:27:14 2008 -0700 ++++ openjdk/jdk/src/windows/classes/sun/awt/Win32GraphicsEnvironment.java Fri Sep 12 15:01:45 2008 -0700 +@@ -393,4 +393,9 @@ + private static void dwmCompositionChanged(boolean enabled) { + isDWMCompositionEnabled = enabled; + } ++ ++ @Override ++ public boolean isDisplayLocal() { ++ return true; ++ } + } +exporting patch: + From dlila at redhat.com Thu Apr 28 05:33:08 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 28 Apr 2011 08:33:08 -0400 (EDT) Subject: [RFC][icedtea6]: backports - AA drawing to screen performance In-Reply-To: <20110428121803.GM28246@rivendell.middle-earth.co.uk> Message-ID: <755078638.1063906.1303993988103.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > > I'm sorry, I forgot to attach the patch. > > > > ----- Original Message ----- > > > > > > > > Regards, > > > Denis. > > Looks good. Please commit to HEAD. Thanks. Done. Regards, Denis. ----- Original Message ----- > On 12:04 Wed 27 Apr , Denis Lila wrote: > > > Hi I would like to backport these two changesets: > > > > > > http://hg.openjdk.java.net/jdk7/2d/jdk/rev/b8f91ea2fb33 > > > http://hg.openjdk.java.net/jdk7/2d/jdk/rev/15435c60c751 > > > > > > The first one refactors a bit of stuff, and puts an abstract > > > method in SunGraphicsEnvironment, which is needed by the > > > second patch. The second changeset (which is the whole point > > > for this) drastically speeds up certain screen rendering > > > operations. > > > > > > Unfortunately, it modifies a couple of files that are also > > > modified > > > by the xrender-01.patch, so that had to be changed to make get > > > both > > > patches apply. > > > > > > ChangeLog: > > > 2011-04-27 Denis Lila > > > > > > * Makefile.am: Apply patches. > > > * NEWS: Update with backports. > > > * patches/openjdk/6748082-isDisplayLocal.patch: New patch. > > > * patches/openjdk/6708580-exa_slow.patch: New patch. Speeds > > > up certain rendering operations. > > > * patches/openjdk/6307603-xrender-01.patch: Make it apply when > > > the previous patch has been applied before it. > > > > > > > > > How does it look? (I tested it of course. It built, and it does > > > give > > > a huge speedup) > > > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 28 05:47:24 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 28 Apr 2011 13:47:24 +0100 Subject: RFC: drop patches/ssl.patch In-Reply-To: <4DB88DAF.6030505@redhat.com> References: <4DB73999.5070601@redhat.com> <20110427145007.GE28246@rivendell.middle-earth.co.uk> <4DB88DAF.6030505@redhat.com> Message-ID: <20110428124724.GO28246@rivendell.middle-earth.co.uk> On 17:42 Wed 27 Apr , Omair Majid wrote: snip... > On 04/27/2011 10:50 AM, Dr Andrew John Hughes wrote: > > Have you tested this with a full build, i.e. not with --disable-bootstrap which I know is > > how you tend to build? > > > > Yes. In fact, (after the screw-up last week) I am now building > icedtea{6,7} using just ./configure. I will build it again before I push. > What screwup? Maybe you shouldn't have mentioned it. > > I've already dropped it from 7. > > Yes, I saw that it was missing. I was trying to find out if I should add > it to icedtea7 or drop it even from icedtea6. > No, I don't want it back in IcedTea 7. It won't apply anyway. > > I couldn't find any record of why it was added (pre-1.0 > > if I recall correctly) and I think it was probably down to when we were using GNU Crypto > > to provide cryptography, before Sun released theirs as part of OpenJDK. > > The icedtea6 changeset a51ee3008713 indicates that it was added when > openjdk6 started providing crypto. But you are more familiar with the > history than I am. > What I managed to dig up is above. I'm happy to drop it. If someone wants it, let them scream. > Cheers, > Omair -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Thu Apr 28 05:55:08 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 28 Apr 2011 13:55:08 +0100 Subject: RFC: Forward port icedtea6's debug-dir patch to icedtea7 In-Reply-To: <4DB82579.9080205@redhat.com> References: <4DB05FDD.1070509@redhat.com> <20110427125330.GB28246@rivendell.middle-earth.co.uk> <4DB82579.9080205@redhat.com> Message-ID: <20110428125508.GP28246@rivendell.middle-earth.co.uk> On 10:17 Wed 27 Apr , Omair Majid wrote: > On 04/27/2011 08:53 AM, Dr Andrew John Hughes wrote: > > On 12:48 Thu 21 Apr , Omair Majid wrote: > >> Hi, > >> > >> The debug-dir patch from icedtea6 needs to be added to icedtea7. Without > >> this patch, a 'make icedtea-debug' creates a openjdk.build-debug dir > >> which is essentially empty, but places the build in actually (on my > >> macine) linux-amd64-debug under the current directory. > >> > >> The attached patch is the trivial port. Okay to commit? > >> > >> ChangeLog: > >> 2011-04-21 Omair Majid > >> > >> * Makefile.am (ICEDTEA_PATCHES): Add debug-dir.patch > >> * patches/debug-dir.patch: New file. Forward port from icedtea6. > >> > >> Cheers, > >> Omair > > > > No. This needs to go in the IcedTea forest at a minimum, not IcedTea7. > > > > Has this not been pushed upstream? > > I think this was originally a backport from upstream. But since then, > upstream has reverted the change: > http://hg.openjdk.java.net/jdk7/tl/diff/47f6b7db1882/Makefile > > So I am not sure if they will be willing to accept this patch. Perhaps > if it was special cased for non-windows platforms, they might be more > forthcoming. > Can you explain what the point of the patch is? I don't even remember this going in. > Thanks, > Omair -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From dlila at redhat.com Thu Apr 28 06:30:20 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 28 Apr 2011 09:30:20 -0400 (EDT) Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <1211439449.1064946.1303996636474.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1939966521.1065302.1303997420711.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. When run as an applet, http://www.sweethome3d.com/index.jsp is broken. To see this, go to "lights", and try to drag one of them to the right. Nothing will happen, and a lot of exceptions will be thrown. The attached patch fixes that. I believe a good enough explanation of what's happening is in the comments (if I'm wrong, don't hesitate to ask). ChangeLog: 2011-04-28 Denis Lila * netx/net/sourceforge/jnlp/NetxPanel.java: Remove unused import. Add SuppressWarnings("serial") (futureTG): New member. (getFutureTG): New method. (run): Remove. No longer needed. (NetxPanel): Initialize futureTG. (createAppletThread): Use futureTG instead of creating a thread group on the spot. * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java: (createPanel): Initialize and frame the panel in a separate thread. Any comments are much appreciated. Regards, Denis. From dlila at redhat.com Thu Apr 28 06:33:21 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 28 Apr 2011 09:33:21 -0400 (EDT) Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <1939966521.1065302.1303997420711.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1382930312.1065355.1303997601785.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > The attached patch fixes that. I believe a good enough > explanation of what's happening is in the comments (if I'm > wrong, don't hesitate to ask). Eh, I forgot the attachment again. ----- Original Message ----- > Hi. > > When run as an applet, http://www.sweethome3d.com/index.jsp > is broken. To see this, go to "lights", and try to drag one > of them to the right. Nothing will happen, and a lot of > exceptions will be thrown. > > > ChangeLog: > 2011-04-28 Denis Lila > > * netx/net/sourceforge/jnlp/NetxPanel.java: > Remove unused import. > Add SuppressWarnings("serial") > (futureTG): New member. > (getFutureTG): New method. > (run): Remove. No longer needed. > (NetxPanel): Initialize futureTG. > (createAppletThread): Use futureTG instead of creating a thread group > on the spot. > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java: > (createPanel): Initialize and frame the panel in a separate thread. > > Any comments are much appreciated. > > Regards, > Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: awt-classloading.patch Type: text/x-patch Size: 5350 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110428/2259dabe/awt-classloading.patch From dlila at redhat.com Thu Apr 28 07:52:20 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 28 Apr 2011 10:52:20 -0400 (EDT) Subject: [RFC][icedtea6]: Backport - NaN in stroked quadratic paths. In-Reply-To: <1570068779.1079119.1304002151043.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <771573572.1080029.1304002340421.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hi. This is my latest bugfix for the openjdk7 2d forest. I would like to backport it into icedtea6. Good to go? ChangeLog: +2011-04-28 Denis Lila + + * Makefile.am: Apply patch. + * NEWS: Update with backport. + * patches/openjdk/7036754-stroker-nan.patch: New patch. Fix NaN + quad stroking problem. + Thank you, Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: stroker-nan.patch Type: text/x-patch Size: 23285 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110428/3f7f4872/stroker-nan.patch From omajid at redhat.com Thu Apr 28 08:04:20 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 28 Apr 2011 11:04:20 -0400 Subject: [icedtea-web] RFC: support configure's --program-suffix option Message-ID: <4DB981F4.2040306@redhat.com> Hi, The attached patch makes icedtea-web support configure's --program-suffix option. A number of distributions use alternatives to manage /usr/bin/javaws. Using a prefix of /usr makes IcedTea-Web's javaws conflict with the alternatives-managed /usr/bin/javaws. Using a --program-suffix is one way to work around this problem and the patch makes this option work. This patch does not modify the names of desktop files, but does fix the binary names they point to. I would like to add this to HEAD and 1.1. Does anyone have any thoughts or comments? ChangeLog 2011-04-28 Omair Majid * Makefile.am (javaws, itweb_settings): New variables. (edit_launcher_script, all-local, install-exe-local) (uninstall-local, clean-launchers, javaws.desktop) (itweb-settings.desktop): Replace all uses of javaws and itweb-settings with the new varaibles. (launcher.build/javaws): Replace with ... (launcher.build/$(javaws)): New target. (launcher.build/itweb-settings): Replace with... (launcher.build/$(itweb-settings)): New target. Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea-web-program-suffix-01.patch Type: text/x-patch Size: 3705 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110428/bcb971d9/icedtea-web-program-suffix-01.patch From dbhole at redhat.com Thu Apr 28 08:29:41 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 28 Apr 2011 11:29:41 -0400 Subject: [icedtea-web] RFC: support configure's --program-suffix option In-Reply-To: <4DB981F4.2040306@redhat.com> References: <4DB981F4.2040306@redhat.com> Message-ID: <20110428152940.GB31776@redhat.com> * Omair Majid [2011-04-28 11:05]: > Hi, > > The attached patch makes icedtea-web support configure's > --program-suffix option. > > A number of distributions use alternatives to manage > /usr/bin/javaws. Using a prefix of /usr makes IcedTea-Web's javaws > conflict with the alternatives-managed /usr/bin/javaws. Using a > --program-suffix is one way to work around this problem and the > patch makes this option work. > > This patch does not modify the names of desktop files, but does fix > the binary names they point to. > > I would like to add this to HEAD and 1.1. Does anyone have any > thoughts or comments? > Changes look fine to me. However I am not sure if itweb-settings needs to be changed too. It is IcedTea-Web specific and quite unlikely to have alternatives at any point in the future. Cheers, Deepak > ChangeLog > 2011-04-28 Omair Majid > > * Makefile.am (javaws, itweb_settings): New variables. > (edit_launcher_script, all-local, install-exe-local) > (uninstall-local, clean-launchers, javaws.desktop) > (itweb-settings.desktop): Replace all uses of javaws and > itweb-settings with the new varaibles. > (launcher.build/javaws): Replace with ... > (launcher.build/$(javaws)): New target. > (launcher.build/itweb-settings): Replace with... > (launcher.build/$(itweb-settings)): New target. > > Thanks, > Omair > diff -r 6abf7a788f4e Makefile.am > --- a/Makefile.am Wed Apr 20 16:33:18 2011 -0400 > +++ b/Makefile.am Thu Apr 28 11:03:39 2011 -0400 > @@ -109,20 +109,24 @@ > EXTRA_DIST = $(top_srcdir)/netx $(top_srcdir)/plugin javaws.png javaws.desktop.in extra launcher \ > itweb-settings.desktop.in $(top_srcdir)/tests > > +# binary names > +javaws:= $(shell echo javaws | sed '@program_transform_name@') > +itweb_settings:= $(shell echo itweb-settings | sed '@program_transform_name@') > + > # the launcher needs to know $(bindir) and $(datadir) which can be different at > # make-time from configure-time > edit_launcher_script = sed \ > -e 's|[@]LAUNCHER_BOOTCLASSPATH[@]|$(LAUNCHER_BOOTCLASSPATH)|g' \ > - -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/javaws|g' \ > - -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/itweb-settings|g' \ > + -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/$(javaws)|g' \ > + -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/$(itweb_settings)|g' \ > -e 's|[@]JAVA[@]|$(JAVA)|g' \ > -e 's|[@]JRE[@]|$(JRE)|g' > > # Top-Level Targets > # ================= > > -all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/javaws \ > - javaws.desktop stamps/docs.stamp launcher.build/itweb-settings itweb-settings.desktop > +all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/$(javaws) \ > + javaws.desktop stamps/docs.stamp launcher.build/$(itweb_settings) itweb-settings.desktop > > check-local: $(RHINO_TESTS) $(JUNIT_TESTS) > > @@ -144,9 +148,9 @@ > ${INSTALL_DATA} $(abs_top_builddir)/liveconnect/lib/classes.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/plugin.jar > endif > ${INSTALL_DATA} $(NETX_DIR)/lib/classes.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/netx.jar > - ${INSTALL_PROGRAM} launcher.build/javaws $(DESTDIR)$(bindir) > + ${INSTALL_PROGRAM} launcher.build/$(javaws) $(DESTDIR)$(bindir) > ${INSTALL_DATA} extra-lib/about.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jar > - ${INSTALL_PROGRAM} launcher.build/itweb-settings $(DESTDIR)$(bindir) > + ${INSTALL_PROGRAM} launcher.build/$(itweb_settings) $(DESTDIR)$(bindir) > > install-data-local: > ${mkinstalldirs} -d $(DESTDIR)$(mandir)/man1 > @@ -175,8 +179,8 @@ > rm -f $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jnlp > rm -f $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jar > rm -f $(DESTDIR)$(mandir)/man1/javaws.1 > - rm -f $(DESTDIR)$(bindir)/javaws > - rm -f $(DESTDIR)$(bindir)/itweb-settings > + rm -f $(DESTDIR)$(bindir)/$(javaws) > + rm -f $(DESTDIR)$(bindir)/$(itweb_settings) > rm -rf $(DESTDIR)$(htmldir) > > # Plugin > @@ -352,26 +356,26 @@ > extra-lib/about.jar: stamps/extra-class-files.stamp > $(BOOT_DIR)/bin/jar cf $@ -C extra-lib net ; > > -launcher.build/javaws: launcher/javaws.in > +launcher.build/$(javaws): launcher/javaws.in > mkdir -p launcher.build > $(edit_launcher_script) < $< > $@ > > -launcher.build/itweb-settings: launcher/itweb-settings.in > +launcher.build/$(itweb_settings): launcher/itweb-settings.in > mkdir -p launcher.build > $(edit_launcher_script) < $< > $@ > > clean-launchers: > - rm -f launcher.build/javaws > - rm -f launcher.build/itweb-settings > + rm -f launcher.build/$(javaws) > + rm -f launcher.build/$(itweb_settings) > if [ -e launcher.build ] ; then \ > rmdir launcher.build ; \ > fi > > javaws.desktop: javaws.desktop.in > - sed "s#PATH_TO_JAVAWS#$(bindir)/javaws#" < $(srcdir)/javaws.desktop.in > javaws.desktop > + sed "s#PATH_TO_JAVAWS#$(bindir)/$(javaws)#" < $(srcdir)/javaws.desktop.in > javaws.desktop > > itweb-settings.desktop: $(srcdir)/itweb-settings.desktop.in > - sed "s#PATH_TO_ITWEB_SETTINGS#$(bindir)/itweb-settings#" \ > + sed "s#PATH_TO_ITWEB_SETTINGS#$(bindir)/$(itweb_settings)#" \ > < $(srcdir)/itweb-settings.desktop.in > itweb-settings.desktop > > # documentation From omajid at redhat.com Thu Apr 28 08:36:47 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 28 Apr 2011 11:36:47 -0400 Subject: [icedtea-web] RFC: support configure's --program-suffix option In-Reply-To: <20110428152940.GB31776@redhat.com> References: <4DB981F4.2040306@redhat.com> <20110428152940.GB31776@redhat.com> Message-ID: <4DB9898F.1050402@redhat.com> On 04/28/2011 11:29 AM, Deepak Bhole wrote: > * Omair Majid [2011-04-28 11:05]: >> Hi, >> >> The attached patch makes icedtea-web support configure's >> --program-suffix option. >> >> A number of distributions use alternatives to manage >> /usr/bin/javaws. Using a prefix of /usr makes IcedTea-Web's javaws >> conflict with the alternatives-managed /usr/bin/javaws. Using a >> --program-suffix is one way to work around this problem and the >> patch makes this option work. >> >> This patch does not modify the names of desktop files, but does fix >> the binary names they point to. >> >> I would like to add this to HEAD and 1.1. Does anyone have any >> thoughts or comments? >> > > Changes look fine to me. However I am not sure if itweb-settings needs > to be changed too. It is IcedTea-Web specific and quite unlikely to have > alternatives at any point in the future. > I agree that we should not see problems with itweb-settings. On the other hand, --program-suffix will allow you to install two different versions of itweb-settings with different names (say itweb-settings11 and itweb-settings12) side by side (though I dont see why someone would want to do this). Also applying the value of --program-suffix to only selected binaries breaks the meaning of --program-suffix. What do you think of having a special --javaws-suffix option? >> ChangeLog >> 2011-04-28 Omair Majid >> >> * Makefile.am (javaws, itweb_settings): New variables. >> (edit_launcher_script, all-local, install-exe-local) >> (uninstall-local, clean-launchers, javaws.desktop) >> (itweb-settings.desktop): Replace all uses of javaws and >> itweb-settings with the new varaibles. >> (launcher.build/javaws): Replace with ... >> (launcher.build/$(javaws)): New target. >> (launcher.build/itweb-settings): Replace with... >> (launcher.build/$(itweb-settings)): New target. >> >> Thanks, >> Omair > >> diff -r 6abf7a788f4e Makefile.am >> --- a/Makefile.am Wed Apr 20 16:33:18 2011 -0400 >> +++ b/Makefile.am Thu Apr 28 11:03:39 2011 -0400 >> @@ -109,20 +109,24 @@ >> EXTRA_DIST = $(top_srcdir)/netx $(top_srcdir)/plugin javaws.png javaws.desktop.in extra launcher \ >> itweb-settings.desktop.in $(top_srcdir)/tests >> >> +# binary names >> +javaws:= $(shell echo javaws | sed '@program_transform_name@') >> +itweb_settings:= $(shell echo itweb-settings | sed '@program_transform_name@') >> + >> # the launcher needs to know $(bindir) and $(datadir) which can be different at >> # make-time from configure-time >> edit_launcher_script = sed \ >> -e 's|[@]LAUNCHER_BOOTCLASSPATH[@]|$(LAUNCHER_BOOTCLASSPATH)|g' \ >> - -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/javaws|g' \ >> - -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/itweb-settings|g' \ >> + -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/$(javaws)|g' \ >> + -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/$(itweb_settings)|g' \ >> -e 's|[@]JAVA[@]|$(JAVA)|g' \ >> -e 's|[@]JRE[@]|$(JRE)|g' >> >> # Top-Level Targets >> # ================= >> >> -all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/javaws \ >> - javaws.desktop stamps/docs.stamp launcher.build/itweb-settings itweb-settings.desktop >> +all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/$(javaws) \ >> + javaws.desktop stamps/docs.stamp launcher.build/$(itweb_settings) itweb-settings.desktop >> >> check-local: $(RHINO_TESTS) $(JUNIT_TESTS) >> >> @@ -144,9 +148,9 @@ >> ${INSTALL_DATA} $(abs_top_builddir)/liveconnect/lib/classes.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/plugin.jar >> endif >> ${INSTALL_DATA} $(NETX_DIR)/lib/classes.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/netx.jar >> - ${INSTALL_PROGRAM} launcher.build/javaws $(DESTDIR)$(bindir) >> + ${INSTALL_PROGRAM} launcher.build/$(javaws) $(DESTDIR)$(bindir) >> ${INSTALL_DATA} extra-lib/about.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jar >> - ${INSTALL_PROGRAM} launcher.build/itweb-settings $(DESTDIR)$(bindir) >> + ${INSTALL_PROGRAM} launcher.build/$(itweb_settings) $(DESTDIR)$(bindir) >> >> install-data-local: >> ${mkinstalldirs} -d $(DESTDIR)$(mandir)/man1 >> @@ -175,8 +179,8 @@ >> rm -f $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jnlp >> rm -f $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jar >> rm -f $(DESTDIR)$(mandir)/man1/javaws.1 >> - rm -f $(DESTDIR)$(bindir)/javaws >> - rm -f $(DESTDIR)$(bindir)/itweb-settings >> + rm -f $(DESTDIR)$(bindir)/$(javaws) >> + rm -f $(DESTDIR)$(bindir)/$(itweb_settings) >> rm -rf $(DESTDIR)$(htmldir) >> >> # Plugin >> @@ -352,26 +356,26 @@ >> extra-lib/about.jar: stamps/extra-class-files.stamp >> $(BOOT_DIR)/bin/jar cf $@ -C extra-lib net ; >> >> -launcher.build/javaws: launcher/javaws.in >> +launcher.build/$(javaws): launcher/javaws.in >> mkdir -p launcher.build >> $(edit_launcher_script)< $< > $@ >> >> -launcher.build/itweb-settings: launcher/itweb-settings.in >> +launcher.build/$(itweb_settings): launcher/itweb-settings.in >> mkdir -p launcher.build >> $(edit_launcher_script)< $< > $@ >> >> clean-launchers: >> - rm -f launcher.build/javaws >> - rm -f launcher.build/itweb-settings >> + rm -f launcher.build/$(javaws) >> + rm -f launcher.build/$(itweb_settings) >> if [ -e launcher.build ] ; then \ >> rmdir launcher.build ; \ >> fi >> >> javaws.desktop: javaws.desktop.in >> - sed "s#PATH_TO_JAVAWS#$(bindir)/javaws#"< $(srcdir)/javaws.desktop.in> javaws.desktop >> + sed "s#PATH_TO_JAVAWS#$(bindir)/$(javaws)#"< $(srcdir)/javaws.desktop.in> javaws.desktop >> >> itweb-settings.desktop: $(srcdir)/itweb-settings.desktop.in >> - sed "s#PATH_TO_ITWEB_SETTINGS#$(bindir)/itweb-settings#" \ >> + sed "s#PATH_TO_ITWEB_SETTINGS#$(bindir)/$(itweb_settings)#" \ >> < $(srcdir)/itweb-settings.desktop.in> itweb-settings.desktop >> >> # documentation > From omajid at redhat.com Thu Apr 28 08:54:32 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 28 Apr 2011 11:54:32 -0400 Subject: RFC: Mark stack as non-executable In-Reply-To: <20110428120520.GJ28246@rivendell.middle-earth.co.uk> References: <4DB82D07.8030902@redhat.com> <20110428120520.GJ28246@rivendell.middle-earth.co.uk> Message-ID: <4DB98DB8.2010306@redhat.com> On 04/28/2011 08:05 AM, Dr Andrew John Hughes wrote: > On 10:49 Wed 27 Apr , Omair Majid wrote: >> Hi, >> >> This patch for the icedtea7 forest (hotspot repo), ported from IcedTea6, >> marks libjvm.so's stack as non-executable. >> >> This patch should really be pushed upstream, but it was originally >> written by Kees Cook who is not on the list of SCA signatories [1]. >> >> Any comments? >> >> Thanks, >> Omair >> >> [1] http://sca.java.net/CA_signatories.htm > > I thought there was some effort to get it upstream. Have you checked the > archives? > Yes, the last email I found was: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2009-August/007037.html Kees hasn't posted a response yet. I did however, find a very similar patch posted by Diego "Flameeyes" Petten for an older hotspot: http://mail.openjdk.java.net/pipermail/hotspot-dev/2007-May/000000.html Diego is on the list at http://sca.java.net/CA_signatories.htm#p. Perhaps if I start from Diego's patch and update it to work with newer hotspot, upstream might accept it. Thanks, Omair From omajid at redhat.com Thu Apr 28 09:07:15 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 28 Apr 2011 12:07:15 -0400 Subject: RFC: drop patches/ssl.patch In-Reply-To: <20110428124724.GO28246@rivendell.middle-earth.co.uk> References: <4DB73999.5070601@redhat.com> <20110427145007.GE28246@rivendell.middle-earth.co.uk> <4DB88DAF.6030505@redhat.com> <20110428124724.GO28246@rivendell.middle-earth.co.uk> Message-ID: <4DB990B3.8030406@redhat.com> On 04/28/2011 08:47 AM, Dr Andrew John Hughes wrote: > On 17:42 Wed 27 Apr , Omair Majid wrote: > > snip... > >> On 04/27/2011 10:50 AM, Dr Andrew John Hughes wrote: >>> Have you tested this with a full build, i.e. not with --disable-bootstrap which I know is >>> how you tend to build? >>> >> >> Yes. In fact, (after the screw-up last week) I am now building >> icedtea{6,7} using just ./configure. I will build it again before I push. >> > > What screwup? Maybe you shouldn't have mentioned it. Doh :) For the record, I pushed a commit (92ce3a01d889) that broke building without --disable-boostrap. I reverted the patch when I discovered the problem. > >>> I've already dropped it from 7. > > If someone wants it, let them scream. > I will do another icedtea6 build (with just ./configure) and push it to icedtea6 if I don't see any problems. Thanks, Omair From ahughes at redhat.com Thu Apr 28 09:21:37 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Thu, 28 Apr 2011 17:21:37 +0100 Subject: [icedtea-web] RFC: support configure's --program-suffix option In-Reply-To: <4DB9898F.1050402@redhat.com> References: <4DB981F4.2040306@redhat.com> <20110428152940.GB31776@redhat.com> <4DB9898F.1050402@redhat.com> Message-ID: <20110428162137.GQ28246@rivendell.middle-earth.co.uk> On 11:36 Thu 28 Apr , Omair Majid wrote: > On 04/28/2011 11:29 AM, Deepak Bhole wrote: > > * Omair Majid [2011-04-28 11:05]: > >> Hi, > >> > >> The attached patch makes icedtea-web support configure's > >> --program-suffix option. > >> > >> A number of distributions use alternatives to manage > >> /usr/bin/javaws. Using a prefix of /usr makes IcedTea-Web's javaws > >> conflict with the alternatives-managed /usr/bin/javaws. Using a > >> --program-suffix is one way to work around this problem and the > >> patch makes this option work. > >> > >> This patch does not modify the names of desktop files, but does fix > >> the binary names they point to. > >> > >> I would like to add this to HEAD and 1.1. Does anyone have any > >> thoughts or comments? > >> > > > > Changes look fine to me. However I am not sure if itweb-settings needs > > to be changed too. It is IcedTea-Web specific and quite unlikely to have > > alternatives at any point in the future. > > > > I agree that we should not see problems with itweb-settings. On the > other hand, --program-suffix will allow you to install two different > versions of itweb-settings with different names (say itweb-settings11 > and itweb-settings12) side by side (though I dont see why someone would > want to do this). > > Also applying the value of --program-suffix to only selected binaries > breaks the meaning of --program-suffix. What do you think of having a > special --javaws-suffix option? > I think the original patch is fine and both should support the option. There's no harm in providing the option to do it even if you personally can't think of a reason to. The facility is there if someone wants to use it. As Omair says, installing 1.1 and 2.0 would be one such case. -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at redhat.com Thu Apr 28 09:33:02 2011 From: omajid at redhat.com (Omair Majid) Date: Thu, 28 Apr 2011 12:33:02 -0400 Subject: RFC: Forward port icedtea6's debug-dir patch to icedtea7 In-Reply-To: <20110428125508.GP28246@rivendell.middle-earth.co.uk> References: <4DB05FDD.1070509@redhat.com> <20110427125330.GB28246@rivendell.middle-earth.co.uk> <4DB82579.9080205@redhat.com> <20110428125508.GP28246@rivendell.middle-earth.co.uk> Message-ID: <4DB996BE.7040404@redhat.com> On 04/28/2011 08:55 AM, Dr Andrew John Hughes wrote: > On 10:17 Wed 27 Apr , Omair Majid wrote: >> On 04/27/2011 08:53 AM, Dr Andrew John Hughes wrote: >>> On 12:48 Thu 21 Apr , Omair Majid wrote: >>>> Hi, >>>> >>>> The debug-dir patch from icedtea6 needs to be added to icedtea7. Without >>>> this patch, a 'make icedtea-debug' creates a openjdk.build-debug dir >>>> which is essentially empty, but places the build in actually (on my >>>> macine) linux-amd64-debug under the current directory. >>>> >>>> The attached patch is the trivial port. Okay to commit? >>>> >>>> ChangeLog: >>>> 2011-04-21 Omair Majid >>>> >>>> * Makefile.am (ICEDTEA_PATCHES): Add debug-dir.patch >>>> * patches/debug-dir.patch: New file. Forward port from icedtea6. >>>> >>>> Cheers, >>>> Omair >>> >>> No. This needs to go in the IcedTea forest at a minimum, not IcedTea7. >>> >>> Has this not been pushed upstream? >> >> I think this was originally a backport from upstream. But since then, >> upstream has reverted the change: >> http://hg.openjdk.java.net/jdk7/tl/diff/47f6b7db1882/Makefile >> >> So I am not sure if they will be willing to accept this patch. Perhaps >> if it was special cased for non-windows platforms, they might be more >> forthcoming. >> > > Can you explain what the point of the patch is? I don't even remember this > going in. > The icedtea6 patch (debug-dir.patch) causes 'make icedtea-debug' to build openjdk in openjdk.build-debug. Without this patch 'make icedtea-debug' builds in linux-amd64-debug (or another appropriate name based on your platform/arch). Upstream actually had this fix for a while, but revered it [1]. It was, presumably, causing problems with paths on windows. What's weird is that upstream's change breaks ALT_OUTPUTDIR for debug/fastdebug builds. Thanks, Omair [1] http://hg.openjdk.java.net/jdk7/tl/diff/47f6b7db1882/Makefile From dbhole at redhat.com Thu Apr 28 09:37:22 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Thu, 28 Apr 2011 12:37:22 -0400 Subject: [icedtea-web] RFC: support configure's --program-suffix option In-Reply-To: <20110428162137.GQ28246@rivendell.middle-earth.co.uk> References: <4DB981F4.2040306@redhat.com> <20110428152940.GB31776@redhat.com> <4DB9898F.1050402@redhat.com> <20110428162137.GQ28246@rivendell.middle-earth.co.uk> Message-ID: <20110428163722.GC31776@redhat.com> * Dr Andrew John Hughes [2011-04-28 12:21]: > On 11:36 Thu 28 Apr , Omair Majid wrote: > > On 04/28/2011 11:29 AM, Deepak Bhole wrote: > > > * Omair Majid [2011-04-28 11:05]: > > >> Hi, > > >> > > >> The attached patch makes icedtea-web support configure's > > >> --program-suffix option. > > >> > > >> A number of distributions use alternatives to manage > > >> /usr/bin/javaws. Using a prefix of /usr makes IcedTea-Web's javaws > > >> conflict with the alternatives-managed /usr/bin/javaws. Using a > > >> --program-suffix is one way to work around this problem and the > > >> patch makes this option work. > > >> > > >> This patch does not modify the names of desktop files, but does fix > > >> the binary names they point to. > > >> > > >> I would like to add this to HEAD and 1.1. Does anyone have any > > >> thoughts or comments? > > >> > > > > > > Changes look fine to me. However I am not sure if itweb-settings needs > > > to be changed too. It is IcedTea-Web specific and quite unlikely to have > > > alternatives at any point in the future. > > > > > > > I agree that we should not see problems with itweb-settings. On the > > other hand, --program-suffix will allow you to install two different > > versions of itweb-settings with different names (say itweb-settings11 > > and itweb-settings12) side by side (though I dont see why someone would > > want to do this). > > > > Also applying the value of --program-suffix to only selected binaries > > breaks the meaning of --program-suffix. What do you think of having a > > special --javaws-suffix option? > > > > I think the original patch is fine and both should support the option. > There's no harm in providing the option to do it even if you personally > can't think of a reason to. The facility is there if someone wants to > use it. As Omair says, installing 1.1 and 2.0 would be one such case. > Fair enough then. I am okay with this patch for HEAD and 1.1. Cheers, Deepak > > -- > Andrew :) > > Free Java Software Engineer > Red Hat, Inc. (http://www.redhat.com) > > Support Free Java! > Contribute to GNU Classpath and IcedTea > http://www.gnu.org/software/classpath > http://icedtea.classpath.org > PGP Key: F5862A37 (https://keys.indymedia.org/) > Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From omajid at icedtea.classpath.org Thu Apr 28 10:24:27 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Thu, 28 Apr 2011 17:24:27 +0000 Subject: /hg/icedtea6: Drop patches/ssl.patch Message-ID: changeset c82aadb00357 in /hg/icedtea6 details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=c82aadb00357 author: Omair Majid date: Thu Apr 28 12:55:41 2011 -0400 Drop patches/ssl.patch 2011-04-28 Omair Majid Drop ssl.patch * Makefile.am (ICEDTEA_PATCHES): Remove ssl.patch. * patches/ssl.patch: Removed. diffstat: ChangeLog | 6 ++++++ Makefile.am | 1 - patches/ssl.patch | 41 ----------------------------------------- 3 files changed, 6 insertions(+), 42 deletions(-) diffs (71 lines): diff -r ad45dd8bcf45 -r c82aadb00357 ChangeLog --- a/ChangeLog Thu Apr 28 08:36:21 2011 -0400 +++ b/ChangeLog Thu Apr 28 12:55:41 2011 -0400 @@ -1,3 +1,9 @@ +2011-04-28 Omair Majid + + Drop ssl.patch + * Makefile.am (ICEDTEA_PATCHES): Remove ssl.patch. + * patches/ssl.patch: Removed. + 2011-04-28 Denis Lila * Makefile.am: Apply patches. diff -r ad45dd8bcf45 -r c82aadb00357 Makefile.am --- a/Makefile.am Thu Apr 28 08:36:21 2011 -0400 +++ b/Makefile.am Thu Apr 28 12:55:41 2011 -0400 @@ -217,7 +217,6 @@ patches/version.patch \ patches/version-hotspot.patch \ patches/hotspot/$(HSBUILD)/text-relocations.patch \ - patches/ssl.patch \ patches/rmi_amd64.patch \ patches/tools.patch \ patches/use-system-tzdata.patch \ diff -r ad45dd8bcf45 -r c82aadb00357 patches/ssl.patch --- a/patches/ssl.patch Thu Apr 28 08:36:21 2011 -0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,43 +0,0 @@ ---- ../openjdkb23/openjdk/jdk/src/share/classes/sun/security/ssl/Handshaker.java 2007-10-30 04:38:10.000000000 -0400 -+++ openjdk/jdk/src/share/classes/sun/security/ssl/Handshaker.java 2007-11-13 13:06:01.000000000 -0500 -@@ -36,6 +36,7 @@ - import java.security.PrivilegedExceptionAction; - import java.security.PrivilegedActionException; - import java.security.cert.X509Certificate; -+import java.security.spec.AlgorithmParameterSpec; - - import javax.crypto.*; - import javax.crypto.spec.*; -@@ -688,8 +683,8 @@ - SecretKey masterSecret; - try { - KeyGenerator kg = JsseJce.getKeyGenerator("SunTlsMasterSecret"); -- kg.init(spec); -- masterSecret = kg.generateKey(); -+ kg.init((AlgorithmParameterSpec) spec); -+ masterSecret = kg.generateKey(); - } catch (GeneralSecurityException e) { - // For RSA premaster secrets, do not signal a protocol error - // due to the Bleichenbacher attack. See comments further down. ---- ../openjdkb23/openjdk/jdk/src/share/classes/sun/security/ssl/RSAClientKeyExchange.java 2007-10-30 04:38:10.000000000 -0400 -+++ openjdk/jdk/src/share/classes/sun/security/ssl/RSAClientKeyExchange.java 2007-11-13 13:06:42.000000000 -0500 -@@ -36,6 +36,8 @@ - import javax.net.ssl.*; - - import sun.security.internal.spec.TlsRsaPremasterSecretParameterSpec; -+import java.security.spec.AlgorithmParameterSpec; -+ - - /** - * This is the client key exchange message (CLIENT --> SERVER) used with -@@ -104,8 +106,8 @@ - - try { - KeyGenerator kg = JsseJce.getKeyGenerator("SunTlsRsaPremasterSecret"); -- kg.init(new TlsRsaPremasterSecretParameterSpec(major, minor)); -- preMaster = kg.generateKey(); -+ kg.init((AlgorithmParameterSpec) (new TlsRsaPremasterSecretParameterSpec(major, minor))); -+ preMaster = kg.generateKey(); - - Cipher cipher = JsseJce.getCipher(JsseJce.CIPHER_RSA_PKCS1); - cipher.init(Cipher.WRAP_MODE, publicKey, generator); From omajid at icedtea.classpath.org Thu Apr 28 13:23:38 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Thu, 28 Apr 2011 20:23:38 +0000 Subject: /hg/icedtea-web: Support configure's --program-suffix option Message-ID: changeset a9729e1bb762 in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=a9729e1bb762 author: Omair Majid date: Thu Apr 28 16:23:11 2011 -0400 Support configure's --program-suffix option 2011-04-28 Omair Majid * Makefile.am (javaws, itweb_settings): New variables. (edit_launcher_script, all-local, install-exe-local) (uninstall- local, clean-launchers, javaws.desktop) (itweb- settings.desktop): Replace all uses of javaws and itweb-settings with the new variables. (launcher.build/javaws): Replace with ... (launcher.build/$(javaws)): New target. (launcher.build /itweb-settings): Replace with... (launcher.build/$(itweb- settings)): New target. diffstat: ChangeLog | 12 ++++++++++++ Makefile.am | 32 ++++++++++++++++++-------------- 2 files changed, 30 insertions(+), 14 deletions(-) diffs (107 lines): diff -r a348c6cd5915 -r a9729e1bb762 ChangeLog --- a/ChangeLog Thu Apr 21 11:19:28 2011 -0400 +++ b/ChangeLog Thu Apr 28 16:23:11 2011 -0400 @@ -1,3 +1,15 @@ +2011-04-28 Omair Majid + + * Makefile.am (javaws, itweb_settings): New variables. + (edit_launcher_script, all-local, install-exe-local) + (uninstall-local, clean-launchers, javaws.desktop) + (itweb-settings.desktop): Replace all uses of javaws and + itweb-settings with the new variables. + (launcher.build/javaws): Replace with ... + (launcher.build/$(javaws)): New target. + (launcher.build/itweb-settings): Replace with... + (launcher.build/$(itweb-settings)): New target. + 2011-04-21 Deepak Bhole * configure.ac: Bumped version to 1.2pre diff -r a348c6cd5915 -r a9729e1bb762 Makefile.am --- a/Makefile.am Thu Apr 21 11:19:28 2011 -0400 +++ b/Makefile.am Thu Apr 28 16:23:11 2011 -0400 @@ -109,20 +109,24 @@ EXTRA_DIST = $(top_srcdir)/netx $(top_srcdir)/plugin javaws.png javaws.desktop.in extra launcher \ itweb-settings.desktop.in $(top_srcdir)/tests +# binary names +javaws:= $(shell echo javaws | sed '@program_transform_name@') +itweb_settings:= $(shell echo itweb-settings | sed '@program_transform_name@') + # the launcher needs to know $(bindir) and $(datadir) which can be different at # make-time from configure-time edit_launcher_script = sed \ -e 's|[@]LAUNCHER_BOOTCLASSPATH[@]|$(LAUNCHER_BOOTCLASSPATH)|g' \ - -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/javaws|g' \ - -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/itweb-settings|g' \ + -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/$(javaws)|g' \ + -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/$(itweb_settings)|g' \ -e 's|[@]JAVA[@]|$(JAVA)|g' \ -e 's|[@]JRE[@]|$(JRE)|g' # Top-Level Targets # ================= -all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/javaws \ - javaws.desktop stamps/docs.stamp launcher.build/itweb-settings itweb-settings.desktop +all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/$(javaws) \ + javaws.desktop stamps/docs.stamp launcher.build/$(itweb_settings) itweb-settings.desktop check-local: $(RHINO_TESTS) $(JUNIT_TESTS) @@ -144,9 +148,9 @@ ${INSTALL_DATA} $(abs_top_builddir)/liveconnect/lib/classes.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/plugin.jar endif ${INSTALL_DATA} $(NETX_DIR)/lib/classes.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/netx.jar - ${INSTALL_PROGRAM} launcher.build/javaws $(DESTDIR)$(bindir) + ${INSTALL_PROGRAM} launcher.build/$(javaws) $(DESTDIR)$(bindir) ${INSTALL_DATA} extra-lib/about.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jar - ${INSTALL_PROGRAM} launcher.build/itweb-settings $(DESTDIR)$(bindir) + ${INSTALL_PROGRAM} launcher.build/$(itweb_settings) $(DESTDIR)$(bindir) install-data-local: ${mkinstalldirs} -d $(DESTDIR)$(mandir)/man1 @@ -175,8 +179,8 @@ rm -f $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jnlp rm -f $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jar rm -f $(DESTDIR)$(mandir)/man1/javaws.1 - rm -f $(DESTDIR)$(bindir)/javaws - rm -f $(DESTDIR)$(bindir)/itweb-settings + rm -f $(DESTDIR)$(bindir)/$(javaws) + rm -f $(DESTDIR)$(bindir)/$(itweb_settings) rm -rf $(DESTDIR)$(htmldir) # Plugin @@ -352,26 +356,26 @@ extra-lib/about.jar: stamps/extra-class-files.stamp $(BOOT_DIR)/bin/jar cf $@ -C extra-lib net ; -launcher.build/javaws: launcher/javaws.in +launcher.build/$(javaws): launcher/javaws.in mkdir -p launcher.build $(edit_launcher_script) < $< > $@ -launcher.build/itweb-settings: launcher/itweb-settings.in +launcher.build/$(itweb_settings): launcher/itweb-settings.in mkdir -p launcher.build $(edit_launcher_script) < $< > $@ clean-launchers: - rm -f launcher.build/javaws - rm -f launcher.build/itweb-settings + rm -f launcher.build/$(javaws) + rm -f launcher.build/$(itweb_settings) if [ -e launcher.build ] ; then \ rmdir launcher.build ; \ fi javaws.desktop: javaws.desktop.in - sed "s#PATH_TO_JAVAWS#$(bindir)/javaws#" < $(srcdir)/javaws.desktop.in > javaws.desktop + sed "s#PATH_TO_JAVAWS#$(bindir)/$(javaws)#" < $(srcdir)/javaws.desktop.in > javaws.desktop itweb-settings.desktop: $(srcdir)/itweb-settings.desktop.in - sed "s#PATH_TO_ITWEB_SETTINGS#$(bindir)/itweb-settings#" \ + sed "s#PATH_TO_ITWEB_SETTINGS#$(bindir)/$(itweb_settings)#" \ < $(srcdir)/itweb-settings.desktop.in > itweb-settings.desktop # documentation From dlila at redhat.com Thu Apr 28 14:24:22 2011 From: dlila at redhat.com (Denis Lila) Date: Thu, 28 Apr 2011 17:24:22 -0400 (EDT) Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <1382930312.1065355.1303997601785.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1669825315.1097960.1304025862211.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > > The attached patch fixes that. I believe a good enough > > explanation of what's happening is in the comments (if I'm > > wrong, don't hesitate to ask). > > Eh, I forgot the attachment again. Hi. Turns out, this patch is incomplete. Better one attached. It also fixes a problem in the pogo.com games where all keystrokes when chatting are ignored. ChangeLog: +2011-04-28 Denis Lila + + * netx/net/sourceforge/jnlp/NetxPanel.java: + Remove unused import; add imports. + Add SuppressWarnings("serial") + (uKey, uKeyToTG, appContextCreated): New members. + (getFutureTG, createNewAppContext): New methods. + (runLoader): Pass uKey to PluginBridge's constructor. + (run): Remove. No longer needed. + (NetxPanel): Initialize uKey. If it is a new key, make a new thread + group for it and save it in the hash map. + (createAppletThread): Use getFutureTG instead of creating a thread + group on the spot. + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java: + (createPanel): Initialize and frame the panel in a separate thread. + * netx/net/sourceforge/jnlp/Launcher.java: + Remove unused import. + (createApplet, createApplication, createThreadGroup): Replace + AppThreadGroup with ThreadGroup. Remove all calls to setApplication. + * netx/net/sourceforge/jnlp/PluginBridge.java: + (PluginBridge): Remove the uniqueKey initialization logic. Set + uniqueKey to the uKey parameter. + * netx/net/sourceforge/jnlp/runtime/AppThreadGroup.java: + Remove file. + Regards, Denis. ----- Original Message ----- > > > ----- Original Message ----- > > Hi. > >C > > When run as an applet, http://www.sweethome3d.com/index.jsp > > is broken. To see this, go to "lights", and try to drag one > > of them to the right. Nothing will happen, and a lot of > > exceptions will be thrown. > > > > > > > ChangeLog: > > 2011-04-28 Denis Lila > > > > * netx/net/sourceforge/jnlp/NetxPanel.java: > > Remove unused import. > > Add SuppressWarnings("serial") > > (futureTG): New member. > > (getFutureTG): New method. > > (run): Remove. No longer needed. > > (NetxPanel): Initialize futureTG. > > (createAppletThread): Use futureTG instead of creating a thread > > group > > on the spot. > > * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java: > > (createPanel): Initialize and frame the panel in a separate thread. > > > > Any comments are much appreciated. > > > > Regards, > > Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: awt-classloading.patch Type: text/x-patch Size: 16300 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110428/4acee49c/awt-classloading.patch From jvanek at redhat.com Fri Apr 29 02:22:40 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Fri, 29 Apr 2011 11:22:40 +0200 Subject: [icedtea-web] xml output for junit, transformation sheets for daily report Message-ID: <4DBA8360.5020403@redhat.com> This patch add functionality to export xml report form junit testsuite, provides some basic nice transformation for make xml fast readable and navigation-able. Also add filtering of inner classes and jnlp from tests-source package Pavel, is xml-content enough for you? Regards J. -------------- next part -------------- A non-text attachment was scrubbed... Name: tests-xml-output.patch Type: text/x-patch Size: 2197 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110429/21156d8e/tests-xml-output.patch -------------- next part -------------- A non-text attachment was scrubbed... Name: xsl_result.tar.gz Type: application/x-gzip Size: 3775 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110429/21156d8e/xsl_result.tar.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: tests-output.xml Type: text/xml Size: 27776 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110429/21156d8e/tests-output.xml From omajid at icedtea.classpath.org Fri Apr 29 07:56:35 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Fri, 29 Apr 2011 14:56:35 +0000 Subject: /hg/release/icedtea-web-1.1: Support configure's --program-suffi... Message-ID: changeset a0a061a0560d in /hg/release/icedtea-web-1.1 details: http://icedtea.classpath.org/hg/release/icedtea-web-1.1?cmd=changeset;node=a0a061a0560d author: Omair Majid date: Thu Apr 28 16:23:11 2011 -0400 Support configure's --program-suffix option 2011-04-28 Omair Majid * Makefile.am (javaws, itweb_settings): New variables. (edit_launcher_script, all-local, install-exe-local) (uninstall- local, clean-launchers, javaws.desktop) (itweb- settings.desktop): Replace all uses of javaws and itweb-settings with the new variables. (launcher.build/javaws): Replace with ... (launcher.build/$(javaws)): New target. (launcher.build /itweb-settings): Replace with... (launcher.build/$(itweb- settings)): New target. diffstat: ChangeLog | 12 ++++++++++++ Makefile.am | 32 ++++++++++++++++++-------------- 2 files changed, 30 insertions(+), 14 deletions(-) diffs (107 lines): diff -r b60550517945 -r a0a061a0560d ChangeLog --- a/ChangeLog Thu Apr 21 11:08:02 2011 -0400 +++ b/ChangeLog Thu Apr 28 16:23:11 2011 -0400 @@ -1,3 +1,15 @@ +2011-04-28 Omair Majid + + * Makefile.am (javaws, itweb_settings): New variables. + (edit_launcher_script, all-local, install-exe-local) + (uninstall-local, clean-launchers, javaws.desktop) + (itweb-settings.desktop): Replace all uses of javaws and + itweb-settings with the new variables. + (launcher.build/javaws): Replace with ... + (launcher.build/$(javaws)): New target. + (launcher.build/itweb-settings): Replace with... + (launcher.build/$(itweb-settings)): New target. + 2011-04-21 Deepak Bhole * plugin/icedteanp/IcedTeaNPPlugin.cc (consume_message): Use diff -r b60550517945 -r a0a061a0560d Makefile.am --- a/Makefile.am Thu Apr 21 11:08:02 2011 -0400 +++ b/Makefile.am Thu Apr 28 16:23:11 2011 -0400 @@ -109,20 +109,24 @@ EXTRA_DIST = $(top_srcdir)/netx $(top_srcdir)/plugin javaws.png javaws.desktop.in extra launcher \ itweb-settings.desktop.in $(top_srcdir)/tests +# binary names +javaws:= $(shell echo javaws | sed '@program_transform_name@') +itweb_settings:= $(shell echo itweb-settings | sed '@program_transform_name@') + # the launcher needs to know $(bindir) and $(datadir) which can be different at # make-time from configure-time edit_launcher_script = sed \ -e 's|[@]LAUNCHER_BOOTCLASSPATH[@]|$(LAUNCHER_BOOTCLASSPATH)|g' \ - -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/javaws|g' \ - -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/itweb-settings|g' \ + -e 's|[@]JAVAWS_BIN_LOCATION[@]|$(bindir)/$(javaws)|g' \ + -e 's|[@]ITWEB_SETTINGS_BIN_LOCATION[@]|$(bindir)/$(itweb_settings)|g' \ -e 's|[@]JAVA[@]|$(JAVA)|g' \ -e 's|[@]JRE[@]|$(JRE)|g' # Top-Level Targets # ================= -all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/javaws \ - javaws.desktop stamps/docs.stamp launcher.build/itweb-settings itweb-settings.desktop +all-local: stamps/netx-dist.stamp extra-lib/about.jar stamps/plugin.stamp launcher.build/$(javaws) \ + javaws.desktop stamps/docs.stamp launcher.build/$(itweb_settings) itweb-settings.desktop check-local: $(RHINO_TESTS) $(JUNIT_TESTS) @@ -144,9 +148,9 @@ ${INSTALL_DATA} $(abs_top_builddir)/liveconnect/lib/classes.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/plugin.jar endif ${INSTALL_DATA} $(NETX_DIR)/lib/classes.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/netx.jar - ${INSTALL_PROGRAM} launcher.build/javaws $(DESTDIR)$(bindir) + ${INSTALL_PROGRAM} launcher.build/$(javaws) $(DESTDIR)$(bindir) ${INSTALL_DATA} extra-lib/about.jar $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jar - ${INSTALL_PROGRAM} launcher.build/itweb-settings $(DESTDIR)$(bindir) + ${INSTALL_PROGRAM} launcher.build/$(itweb_settings) $(DESTDIR)$(bindir) install-data-local: ${mkinstalldirs} -d $(DESTDIR)$(mandir)/man1 @@ -175,8 +179,8 @@ rm -f $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jnlp rm -f $(DESTDIR)$(datadir)/$(PACKAGE_NAME)/about.jar rm -f $(DESTDIR)$(mandir)/man1/javaws.1 - rm -f $(DESTDIR)$(bindir)/javaws - rm -f $(DESTDIR)$(bindir)/itweb-settings + rm -f $(DESTDIR)$(bindir)/$(javaws) + rm -f $(DESTDIR)$(bindir)/$(itweb_settings) rm -rf $(DESTDIR)$(htmldir) # Plugin @@ -352,26 +356,26 @@ extra-lib/about.jar: stamps/extra-class-files.stamp $(BOOT_DIR)/bin/jar cf $@ -C extra-lib net ; -launcher.build/javaws: launcher/javaws.in +launcher.build/$(javaws): launcher/javaws.in mkdir -p launcher.build $(edit_launcher_script) < $< > $@ -launcher.build/itweb-settings: launcher/itweb-settings.in +launcher.build/$(itweb_settings): launcher/itweb-settings.in mkdir -p launcher.build $(edit_launcher_script) < $< > $@ clean-launchers: - rm -f launcher.build/javaws - rm -f launcher.build/itweb-settings + rm -f launcher.build/$(javaws) + rm -f launcher.build/$(itweb_settings) if [ -e launcher.build ] ; then \ rmdir launcher.build ; \ fi javaws.desktop: javaws.desktop.in - sed "s#PATH_TO_JAVAWS#$(bindir)/javaws#" < $(srcdir)/javaws.desktop.in > javaws.desktop + sed "s#PATH_TO_JAVAWS#$(bindir)/$(javaws)#" < $(srcdir)/javaws.desktop.in > javaws.desktop itweb-settings.desktop: $(srcdir)/itweb-settings.desktop.in - sed "s#PATH_TO_ITWEB_SETTINGS#$(bindir)/itweb-settings#" \ + sed "s#PATH_TO_ITWEB_SETTINGS#$(bindir)/$(itweb_settings)#" \ < $(srcdir)/itweb-settings.desktop.in > itweb-settings.desktop # documentation From omajid at icedtea.classpath.org Fri Apr 29 08:46:17 2011 From: omajid at icedtea.classpath.org (omajid at icedtea.classpath.org) Date: Fri, 29 Apr 2011 15:46:17 +0000 Subject: /hg/icedtea6: Backport S7029905: demo applets missing some html ... Message-ID: changeset c66866782611 in /hg/icedtea6 details: http://icedtea.classpath.org/hg/icedtea6?cmd=changeset;node=c66866782611 author: Omair Majid date: Fri Apr 29 11:46:01 2011 -0400 Backport S7029905: demo applets missing some html files Also drop local patch patches/demo-swingapplet.patch in favor of upstream's fix diffstat: ChangeLog | 8 +++ Makefile.am | 2 +- NEWS | 1 + patches/demo-swingapplet.patch | 10 --- patches/openjdk/7029905-demo_applet_html_files.patch | 52 ++++++++++++++++++++ 5 files changed, 62 insertions(+), 11 deletions(-) diffs (113 lines): diff -r c82aadb00357 -r c66866782611 ChangeLog --- a/ChangeLog Thu Apr 28 12:55:41 2011 -0400 +++ b/ChangeLog Fri Apr 29 11:46:01 2011 -0400 @@ -1,3 +1,11 @@ +2011-04-29 Omair Majid + + * NEWS: Update. + * Makefile.am (ICEDTEA_PATCHES): Replace patches/demo-swingapplet.patch + with patches/openjdk/7029905-demo_applet_html_files.patch. + * patches/demo-swingapplet.patch: Remove. + * patches/openjdk/7029905-demo_applet_html_files.patch: New patch. + 2011-04-28 Omair Majid Drop ssl.patch diff -r c82aadb00357 -r c66866782611 Makefile.am --- a/Makefile.am Thu Apr 28 12:55:41 2011 -0400 +++ b/Makefile.am Fri Apr 29 11:46:01 2011 -0400 @@ -254,7 +254,7 @@ patches/sparc64-linux.patch \ patches/sparc-ptracefix.patch \ patches/sparc-trapsfix.patch \ - patches/demo-swingapplet.patch \ + patches/openjdk/7029905-demo_applet_html_files.patch \ patches/jtreg-6592792.patch \ patches/s390-noinline.patch \ patches/jtreg-dnd.patch \ diff -r c82aadb00357 -r c66866782611 NEWS --- a/NEWS Thu Apr 28 12:55:41 2011 -0400 +++ b/NEWS Fri Apr 29 11:46:01 2011 -0400 @@ -20,6 +20,7 @@ - S7032388, PR682: Make HotSpot work on machines without cmov instruction again - S6748082: remove platform-specific code from SwingUtilities2.isDisplayLocal - S6708580: Java applications slow when EXA enabled + - S7029905: demo applets missing some html files * Bug fixes - PR637: make check should exit with an error code if any regression test failed. - G356743: Support libpng 1.5. diff -r c82aadb00357 -r c66866782611 patches/demo-swingapplet.patch --- a/patches/demo-swingapplet.patch Thu Apr 28 12:55:41 2011 -0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,11 +0,0 @@ ---- openjdk/jdk/make/mkdemo/jfc/SwingApplet/Makefile.orig 2009-01-06 17:07:25.000000000 -0500 -+++ openjdk/jdk/make/mkdemo/jfc/SwingApplet/Makefile 2009-01-06 16:47:28.000000000 -0500 -@@ -33,7 +33,7 @@ - include $(BUILDDIR)/common/Defs.gmk - - DEMO_ROOT = $(SHARE_SRC)/demo/jfc/$(DEMONAME) --DEMO_TOPFILES = ./README.txt -+DEMO_TOPFILES = ./README.txt ./SwingApplet.html - DEMO_MAINCLASS = $(DEMONAME) - DEMO_DESTDIR = $(DEMODIR)/jfc/$(DEMONAME) - diff -r c82aadb00357 -r c66866782611 patches/openjdk/7029905-demo_applet_html_files.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/openjdk/7029905-demo_applet_html_files.patch Fri Apr 29 11:46:01 2011 -0400 @@ -0,0 +1,56 @@ +# HG changeset patch +# User ohair +# Date 1301955066 25200 +# Node ID 9d1f5ad258f89cde283c7c468bfd4d04f91f9c29 +# Parent aa13e7702cd9d8aca9aa38f1227f966990866944 +7029905: demo applets missing some html files +Reviewed-by: omajid, mchung, igor + +diff -r aa13e7702cd9 -r 9d1f5ad258f8 make/mkdemo/jfc/Font2DTest/Makefile +--- openjdk/jdk/make/mkdemo/jfc/Font2DTest/Makefile Tue Mar 29 20:19:55 2011 -0700 ++++ openjdk/jdk/make/mkdemo/jfc/Font2DTest/Makefile Mon Apr 04 15:11:06 2011 -0700 +@@ -33,7 +33,7 @@ + include $(BUILDDIR)/common/Defs.gmk + + DEMO_ROOT = $(SHARE_SRC)/demo/jfc/$(DEMONAME) +-DEMO_TOPFILES = ./README.txt ++DEMO_TOPFILES = ./README.txt ./$(DEMONAME).html + DEMO_MAINCLASS = $(DEMONAME) + DEMO_DESTDIR = $(DEMODIR)/jfc/$(DEMONAME) + +diff -r aa13e7702cd9 -r 9d1f5ad258f8 make/mkdemo/jfc/Java2D/Makefile +--- openjdk/jdk/make/mkdemo/jfc/Java2D/Makefile Tue Mar 29 20:19:55 2011 -0700 ++++ openjdk/jdk/make/mkdemo/jfc/Java2D/Makefile Mon Apr 04 15:11:06 2011 -0700 +@@ -33,7 +33,7 @@ + include $(BUILDDIR)/common/Defs.gmk + + DEMO_ROOT = $(CLOSED_SRC)/share/demo/jfc/Java2D +-DEMO_TOPFILES = ./Java2Demo.html ./README.txt ++DEMO_TOPFILES = ./README.txt ./$(DEMONAME).html + DEMO_MAINCLASS = java2d.Java2Demo + DEMO_DESTDIR = $(DEMODIR)/jfc/Java2D + +diff -r aa13e7702cd9 -r 9d1f5ad258f8 make/mkdemo/jfc/SwingApplet/Makefile +--- openjdk/jdk/make/mkdemo/jfc/SwingApplet/Makefile Tue Mar 29 20:19:55 2011 -0700 ++++ openjdk/jdk/make/mkdemo/jfc/SwingApplet/Makefile Mon Apr 04 15:11:06 2011 -0700 +@@ -33,7 +33,7 @@ + include $(BUILDDIR)/common/Defs.gmk + + DEMO_ROOT = $(SHARE_SRC)/demo/jfc/$(DEMONAME) +-DEMO_TOPFILES = ./README.txt ++DEMO_TOPFILES = ./README.txt ./$(DEMONAME).html + DEMO_MAINCLASS = $(DEMONAME) + DEMO_DESTDIR = $(DEMODIR)/jfc/$(DEMONAME) + +diff -r aa13e7702cd9 -r 9d1f5ad258f8 make/mkdemo/jfc/SwingSet2/Makefile +--- openjdk/jdk/make/mkdemo/jfc/SwingSet2/Makefile Tue Mar 29 20:19:55 2011 -0700 ++++ openjdk/jdk/make/mkdemo/jfc/SwingSet2/Makefile Mon Apr 04 15:11:06 2011 -0700 +@@ -33,7 +33,7 @@ + include $(BUILDDIR)/common/Defs.gmk + + DEMO_ROOT = $(CLOSED_SRC)/share/demo/jfc/$(DEMONAME) +-DEMO_TOPFILES = ./README.txt ++DEMO_TOPFILES = ./README.txt ./$(DEMONAME).html + DEMO_MAINCLASS = $(DEMONAME) + DEMO_MANIFEST_ATTR = SplashScreen-Image: resources/images/splash.png + DEMO_DESTDIR = $(DEMODIR)/jfc/$(DEMONAME) From omajid at redhat.com Fri Apr 29 09:25:45 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 12:25:45 -0400 Subject: RFC: Port libpng1.5 support to icedtea7 Message-ID: <4DBAE689.4070900@redhat.com> Hi, The attached patch for icedtea7 forest (jdk repo) adds support for building with libpng 1.5. It is based on the g356743-libpng-1.5.patch file in icedtea6. Okay to commit? Thanks, Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: icedtea7-jdk-libpng15.patch Type: text/x-patch Size: 933 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110429/22247e24/icedtea7-jdk-libpng15.patch From omajid at redhat.com Fri Apr 29 10:13:32 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 13:13:32 -0400 Subject: RFC: Port libpng1.5 support to icedtea7 In-Reply-To: <4DBAE689.4070900@redhat.com> References: <4DBAE689.4070900@redhat.com> Message-ID: <4DBAF1BC.1090409@redhat.com> On 04/29/2011 12:25 PM, Omair Majid wrote: > Hi, > > The attached patch for icedtea7 forest (jdk repo) adds support for > building with libpng 1.5. It is based on the g356743-libpng-1.5.patch > file in icedtea6. > > Okay to commit? > Just realized that this patch was originally written by Alexis Ballier who has not signed the SCA. Is it ok to add such a patch to the icedtea forest at hg.openjdk.java.net? Or should this be a local patch in icedtea.classpath.org/hg/icedtea ? Thanks, Omair From omajid at redhat.com Fri Apr 29 10:36:24 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 13:36:24 -0400 Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <1669825315.1097960.1304025862211.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1669825315.1097960.1304025862211.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4DBAF718.5040100@redhat.com> On 04/28/2011 05:24 PM, Denis Lila wrote: >>> > > The attached patch fixes that. I believe a good enough >>> > > explanation of what's happening is in the comments (if I'm >>> > > wrong, don't hesitate to ask). >> > >> > Eh, I forgot the attachment again. > Hi. > > Turns out, this patch is incomplete. Better one attached. > It also fixes a problem in the pogo.com games where > all keystrokes when chatting are ignored. > Overall, this patch looks fine to me. Some comments inline. > @@ -39,14 +40,51 @@ > * > * @author Francis Kung > */ > + at SuppressWarnings("serial") > public class NetxPanel extends AppletViewerPanel { Is there a particular reason you are suppressing this warning? > + this.uKey = "codebase=" + codebaseAttr + > + "cache_archive=" + cache_archiveAttr + > + "java_archive=" + java_archiveAttr + > + "archive=" + archiveAttr; > + // TODO: perhaps add some randomization in the name here? > + uKeyToTG.putIfAbsent(this.uKey, new ThreadGroup(Launcher.mainGroup, this.documentURL.toString())); The comment below about the constructor parameters for new {App,}ThreadGroup() should be moved here. > @@ -156,9 +182,7 @@ > > // when this was being done (incorrectly) in Launcher, the call was > // new AppThreadGroup(mainGroup, file.getTitle()); > - ThreadGroup tg = new AppThreadGroup(Launcher.mainGroup, > - this.documentURL.toString()); > - handler = new Thread(tg, this); > + handler = new Thread(getFutureTG(), this); > handler.start(); > } > > @@ -174,4 +198,19 @@ > public boolean isAlive() { > return handler != null&& handler.isAlive()&& this.appletAlive; > } > + > + public ThreadGroup getFutureTG() { > + return uKeyToTG.get(uKey); > + } > + I am not sure if the name getFutureTG is appropriate, espcially given the check currentThreadGroup = getFutureTG() in the next few lines. I think getThreadGroup() would be fine. > + public void createNewAppContext() { > + if (Thread.currentThread().getThreadGroup() != getFutureTG()) { > + throw new RuntimeException("createNewAppContext called from the wrong thread."); > + } > + // only create a new one if one hasn't already been created for the > + // applets with this unique key. > + if (null == appContextCreated.putIfAbsent(uKey, Boolean.TRUE)) { > + SunToolkit.createNewAppContext(); > + } > + } > } ... snip ... > @@ -136,13 +136,29 @@ > } > }); > > - // create the frame. > - PluginAppletViewer.framePanel(identifier, handle, panel); > + // Framing the panel needs to happen in a thread whose thread group > + // is the same as the threadgroup of the applet thread. If this > + // isn't the case, the awt eventqueue thread's context classloader > + // won't be set to a JNLPClassLoader, and when an applet class needs > + // to be loaded from the awt eventqueue, it won't be found. > + Thread panelInit = new Thread(panel.getFutureTG(), new Runnable() { > + @Override public void run() { > + panel.createNewAppContext(); > + // create the frame. > + PluginAppletViewer.framePanel(identifier, handle, panel); > + panel.init(); > + // Start the applet > + initEventQueue(panel); > + } > + }, "NetXPanel initializer"); > > - panel.init(); > - > - // Start the applet > - initEventQueue(panel); > + panelInit.start(); > + while(panelInit.isAlive()) { > + try { > + panelInit.join(); > + } catch (InterruptedException e) { > + } > + } > This part looks fine to me, but I am not too familiar with the concurrency requirements and communication between threads that goes on in PluginAppletViewer. Cheers, Omair From dlila at redhat.com Fri Apr 29 10:53:21 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 29 Apr 2011 13:53:21 -0400 (EDT) Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <4DBAF718.5040100@redhat.com> Message-ID: <1157887844.1148790.1304099601928.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > > + this.uKey = "codebase=" + codebaseAttr + > > + "cache_archive=" + cache_archiveAttr + > > + "java_archive=" + java_archiveAttr + > > + "archive=" + archiveAttr; > > + // TODO: perhaps add some randomization in the name here? > > + uKeyToTG.putIfAbsent(this.uKey, new > > ThreadGroup(Launcher.mainGroup, this.documentURL.toString())); > > The comment below about the constructor parameters for new > {App,}ThreadGroup() should be moved here. Will do. > I am not sure if the name getFutureTG is appropriate, espcially given > the check currentThreadGroup = getFutureTG() in the next few lines. I > think getThreadGroup() would be fine. I agree. That name was getting a bit awkward. > > @@ -39,14 +40,51 @@ > > * > > * @author Francis Kung > > */ > > + at SuppressWarnings("serial") > > public class NetxPanel extends AppletViewerPanel { > > Is there a particular reason you are suppressing this warning? > It's a pet peeve of mine ;) Warning marks in eclipse bother me more than they reasonably should. Should I change it back? > > - // create the frame. > > - PluginAppletViewer.framePanel(identifier, handle, panel); > > + // Framing the panel needs to happen in a thread whose thread > > group > > + // is the same as the threadgroup of the applet thread. If this > > + // isn't the case, the awt eventqueue thread's context classloader > > + // won't be set to a JNLPClassLoader, and when an applet class > > needs > > + // to be loaded from the awt eventqueue, it won't be found. > > + Thread panelInit = new Thread(panel.getFutureTG(), new Runnable() > > { > > + @Override public void run() { > > + panel.createNewAppContext(); > > + // create the frame. > > + PluginAppletViewer.framePanel(identifier, handle, panel); > > + panel.init(); > > + // Start the applet > > + initEventQueue(panel); > > + } > > + }, "NetXPanel initializer"); > > > > - panel.init(); > > - > > - // Start the applet > > - initEventQueue(panel); > > + panelInit.start(); > > + while(panelInit.isAlive()) { > > + try { > > + panelInit.join(); > > + } catch (InterruptedException e) { > > + } > > + } > > > > This part looks fine to me, but I am not too familiar with the > concurrency requirements and communication between threads that goes > on in PluginAppletViewer. This code is meant to be as close to the original as possible, with the exception that it should happen in the same TG as the one of the thread that will do the loading in panel.init() (and with a new AppContext so that we get new eventqueue threads for new applets). What do you think about the TODO? I think you suggested something like that to me yesterday. That's why I put the TODO in there. However, what we have now is what we've always had (as far as the TG name goes), and I wasn't sure I should change it. Thank you, Denis. ----- Original Message ----- > On 04/28/2011 05:24 PM, Denis Lila wrote: > >>> > > The attached patch fixes that. I believe a good enough > >>> > > explanation of what's happening is in the comments (if I'm > >>> > > wrong, don't hesitate to ask). > >> > > >> > Eh, I forgot the attachment again. > > Hi. > > > > Turns out, this patch is incomplete. Better one attached. > > It also fixes a problem in the pogo.com games where > > all keystrokes when chatting are ignored. > > > > Overall, this patch looks fine to me. Some comments inline. > > > > > > @@ -156,9 +182,7 @@ > > > > // when this was being done (incorrectly) in Launcher, the > > call was > > // new AppThreadGroup(mainGroup, file.getTitle()); > > - ThreadGroup tg = new AppThreadGroup(Launcher.mainGroup, > > - this.documentURL.toString()); > > - handler = new Thread(tg, this); > > + handler = new Thread(getFutureTG(), this); > > handler.start(); > > } > > > > @@ -174,4 +198,19 @@ > > public boolean isAlive() { > > return handler != null&& handler.isAlive()&& > > this.appletAlive; > > } > > + > > + public ThreadGroup getFutureTG() { > > + return uKeyToTG.get(uKey); > > + } > > + > > > > + public void createNewAppContext() { > > + if (Thread.currentThread().getThreadGroup() != getFutureTG()) { > > + throw new RuntimeException("createNewAppContext called from the > > wrong thread."); > > + } > > + // only create a new one if one hasn't already been created for > > the > > + // applets with this unique key. > > + if (null == appContextCreated.putIfAbsent(uKey, Boolean.TRUE)) { > > + SunToolkit.createNewAppContext(); > > + } > > + } > > } > > ... snip ... > > > @@ -136,13 +136,29 @@ > > } > > }); > > > > Cheers, > Omair From omajid at redhat.com Fri Apr 29 11:05:28 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 14:05:28 -0400 Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <1157887844.1148790.1304099601928.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1157887844.1148790.1304099601928.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4DBAFDE8.6090302@redhat.com> On 04/29/2011 01:53 PM, Denis Lila wrote: >>> @@ -39,14 +40,51 @@ >>> * >>> * @author Francis Kung >>> */ >>> + at SuppressWarnings("serial") >>> public class NetxPanel extends AppletViewerPanel { >> >> Is there a particular reason you are suppressing this warning? >> > > It's a pet peeve of mine ;) > Warning marks in eclipse bother me more than they reasonably > should. Should I change it back? > If it's a warning and it bothers you, I think we should fix the cause (thought that should be a separate patch), not merely suppress the warning. >>> - // create the frame. >>> - PluginAppletViewer.framePanel(identifier, handle, panel); >>> + // Framing the panel needs to happen in a thread whose thread >>> group >>> + // is the same as the threadgroup of the applet thread. If this >>> + // isn't the case, the awt eventqueue thread's context classloader >>> + // won't be set to a JNLPClassLoader, and when an applet class >>> needs >>> + // to be loaded from the awt eventqueue, it won't be found. >>> + Thread panelInit = new Thread(panel.getFutureTG(), new Runnable() >>> { >>> + @Override public void run() { >>> + panel.createNewAppContext(); >>> + // create the frame. >>> + PluginAppletViewer.framePanel(identifier, handle, panel); >>> + panel.init(); >>> + // Start the applet >>> + initEventQueue(panel); >>> + } >>> + }, "NetXPanel initializer"); >>> >>> - panel.init(); >>> - >>> - // Start the applet >>> - initEventQueue(panel); >>> + panelInit.start(); >>> + while(panelInit.isAlive()) { >>> + try { >>> + panelInit.join(); >>> + } catch (InterruptedException e) { >>> + } >>> + } >>> >> >> This part looks fine to me, but I am not too familiar with the >> concurrency requirements and communication between threads that goes >> on in PluginAppletViewer. > > This code is meant to be as close to the original as possible, with the > exception that it should happen in the same TG as the one of the thread > that will do the loading in panel.init() (and with a new AppContext so > that we get new eventqueue threads for new applets). > > What do you think about the TODO? > I think you suggested something like that to me yesterday. That's why > I put the TODO in there. However, what we have now is what we've always > had (as far as the TG name goes), and I wasn't sure I should change it. > No, I think it's fine for now. AFAIK, knowing the name of the thread group is not sufficient to create other threads in it. As long as other applets cant access/use these other threadgroups, we are fine. Cheers, Omair From dbhole at redhat.com Fri Apr 29 11:37:28 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 29 Apr 2011 14:37:28 -0400 Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <1382930312.1065355.1303997601785.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <1939966521.1065302.1303997420711.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <1382930312.1065355.1303997601785.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <20110429183728.GB16613@redhat.com> * Denis Lila [2011-04-28 09:34]: > > - // create the frame. > - PluginAppletViewer.framePanel(identifier, handle, panel); > + // Framing the panel needs to happen in a thread whose thread group > + // is the same as the threadgroup of the applet thread. If this > + // isn't the case, the awt eventqueue thread's context classloader > + // won't be set to a JNLPClassLoader, and when an applet class needs > + // to be loaded from the awt eventqueue, it won't be found. > + Thread panelInit = new Thread(panel.getFutureTG(), new Runnable() { > + @Override public void run() { > + SunToolkit.createNewAppContext(); > + // create the frame. > + PluginAppletViewer.framePanel(identifier, handle, panel); > + panel.init(); > + // Start the applet > + initEventQueue(panel); > + } > + }, "NetXPanel initializer"); > > - panel.init(); > - > - // Start the applet > - initEventQueue(panel); > + panelInit.start(); > + while(panelInit.isAlive()) { > + try { > + panelInit.join(); > + } catch (InterruptedException e) { > + } > + } > Initialization is a separate thread should be fine, but what is the above while/join trying to achieve? More specifically, why is it a while statement and not an if? Cheers, Deepak > // Wait for the panel to initialize > PluginAppletViewer.waitForAppletInit(panel); From bugzilla-daemon at icedtea.classpath.org Fri Apr 29 11:37:30 2011 From: bugzilla-daemon at icedtea.classpath.org (bugzilla-daemon at icedtea.classpath.org) Date: Fri, 29 Apr 2011 18:37:30 +0000 Subject: [Bug 703] New: ARM T2 JIT java.util.concurrent.ExecutionException during rewriter.stamp Message-ID: http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=703 Summary: ARM T2 JIT java.util.concurrent.ExecutionException during rewriter.stamp Product: IcedTea Version: 6-1.8.7 Platform: arm OS/Version: Linux Status: NEW Severity: normal Priority: P5 Component: Thumb2 JIT AssignedTo: unassigned at icedtea.classpath.org ReportedBy: xerxes at zafena.se The dual-core arm natty-armv7l builder hits this exception in about 1 of 10 builds while using the Thumb2 JIT enabled Icedtea6-1.8 release for bootstrapping. http://builder.classpath.org/icedtea/buildbot/buildslaves/natty-armv7l This bug have so fair not manifest itself when running builds on the single core squeeze-armv5tel builder that does not make use of the thumb2 jit. http://builder.classpath.org/icedtea/buildbot/buildslaves/squeeze-armv5tel Output: touch stamps/rewriter.stamp mkdir -p rhino/rhino.{old,new} && \ (cd rhino/rhino.old ; /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/bootstrap/jdk1.6.0/bin/jar xf /usr/share/java/js.jar) && \ /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/bootstrap/jdk1.6.0/bin/java -cp /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/rewriter.build \ com.redhat.rewriter.ClassRewriter \ /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/rhino/rhino.old /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/rhino/rhino.new \ org.mozilla sun.org.mozilla && \ (cd rhino/rhino.old ; \ for files in `find -type f -not -name '*.class'` ; do \ new_file=../rhino.new/`echo $files|sed -e 's#org#sun/org#'` ; \ mkdir -p `dirname $new_file` ; \ cp -v $files $new_file ; \ sed -ie 's#org\.mozilla#sun.org.mozilla#g' $new_file ; \ done \ ) && \ (cd rhino/rhino.new && \ /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/bootstrap/jdk1.6.0/bin/jar cfm ../rhino.jar META-INF/MANIFEST.MF sun ) Apr 29, 2011 6:08:27 PM com.redhat.rewriter.ClassRewriter processFile INFO: Processing class /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/rhino/rhino.old/org/mozilla/classfile/ClassFileField.class ... Apr 29, 2011 6:08:28 PM com.redhat.rewriter.ClassRewriter processFile INFO: Processing class /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/rhino/rhino.old/org/mozilla/javascript/UintMap.class Apr 29, 2011 6:08:28 PM com.redhat.rewriter.ClassRewriter processFile INFO: Processing class /var/lib/buildbot/icedtea/icedtea6-natty-armv7l-quick/build/rhino/rhino.old/org/mozilla/javascript/ObjToIntMap$Iterator.class Apr 29, 2011 6:08:28 PM com.redhat.rewriter.ClassRewriter main INFO: Waiting for rewrites to complete... Apr 29, 2011 6:08:28 PM com.redhat.rewriter.ClassRewriter main INFO: Checking for errors... Exception in thread "main" java.util.concurrent.ExecutionException: java.lang.NullPointerException: at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:252) at java.util.concurrent.FutureTask.get(FutureTask.java:111) at com.redhat.rewriter.ClassRewriter.main(ClassRewriter.java:98) Caused by: java.lang.NullPointerException: at java.util.regex.Matcher.find(Matcher.java:547) at java.util.regex.Matcher.replaceAll(Matcher.java:819) at java.lang.String.replace(String.java:2219) at com.redhat.rewriter.ClassRewriter.call(ClassRewriter.java:154) at com.redhat.rewriter.ClassRewriter.call(ClassRewriter.java:45) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) make: *** [stamps/rewrite-rhino.stamp] Error 1 program finished with exit code 2 elapsedTime=479.189301 -- Configure bugmail: http://icedtea.classpath.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. From dbhole at redhat.com Fri Apr 29 11:42:02 2011 From: dbhole at redhat.com (Deepak Bhole) Date: Fri, 29 Apr 2011 14:42:02 -0400 Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <20110429183728.GB16613@redhat.com> References: <1939966521.1065302.1303997420711.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <1382930312.1065355.1303997601785.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> <20110429183728.GB16613@redhat.com> Message-ID: <20110429184202.GA19554@redhat.com> * Deepak Bhole [2011-04-29 14:38]: > * Denis Lila [2011-04-28 09:34]: > > > > - // create the frame. > > - PluginAppletViewer.framePanel(identifier, handle, panel); > > + // Framing the panel needs to happen in a thread whose thread group > > + // is the same as the threadgroup of the applet thread. If this > > + // isn't the case, the awt eventqueue thread's context classloader > > + // won't be set to a JNLPClassLoader, and when an applet class needs > > + // to be loaded from the awt eventqueue, it won't be found. > > + Thread panelInit = new Thread(panel.getFutureTG(), new Runnable() { > > + @Override public void run() { > > + SunToolkit.createNewAppContext(); > > + // create the frame. > > + PluginAppletViewer.framePanel(identifier, handle, panel); > > + panel.init(); > > + // Start the applet > > + initEventQueue(panel); > > + } > > + }, "NetXPanel initializer"); > > > > - panel.init(); > > - > > - // Start the applet > > - initEventQueue(panel); > > + panelInit.start(); > > + while(panelInit.isAlive()) { > > + try { > > + panelInit.join(); > > + } catch (InterruptedException e) { > > + } > > + } > > > > Initialization is a separate thread should be fine, but what is the > above while/join trying to achieve? More specifically, why is it a while > statement and not an if? > Gah. Ignore that. Didn't notice the try/catch. Okay, yes, assuming you have tested it, this part of the change to PAV is fine. Cheers, Deepak > Cheers, > Deepak > > > // Wait for the panel to initialize > > PluginAppletViewer.waitForAppletInit(panel); > From dlila at redhat.com Fri Apr 29 13:14:18 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 29 Apr 2011 16:14:18 -0400 (EDT) Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <4DBAFDE8.6090302@redhat.com> Message-ID: <2038785587.1156149.1304108058321.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > If it's a warning and it bothers you, I think we should fix the cause > (thought that should be a separate patch), not merely suppress the > warning. Ok. Although, I don't think we should "fix" it. Doing that would involve inserting a serialVersionUID field, which we only need if we wanted to serialize NetxPanel (which we don't). The compiler generates one itself, so even if we were doing serialization we might not need to introduce that field. Not to mention that putting in that field even though we don't serialize might confuse future readers. > No, I think it's fine for now. AFAIK, knowing the name of the thread > group is not sufficient to create other threads in it. As long as > other applets cant access/use these other threadgroups, we are fine. Hm... other applets can access these thread groups, but only if they have the same uKey, and hence share a classloader. Is that ok? Regards, Denis. ----- Original Message ----- > On 04/29/2011 01:53 PM, Denis Lila wrote: > >>> @@ -39,14 +40,51 @@ > >>> * > >>> * @author Francis Kung > >>> */ > >>> + at SuppressWarnings("serial") > >>> public class NetxPanel extends AppletViewerPanel { > >> > >> Is there a particular reason you are suppressing this warning? > >> > > > > It's a pet peeve of mine ;) > > Warning marks in eclipse bother me more than they reasonably > > should. Should I change it back? > > > > > >>> - // create the frame. > >>> - PluginAppletViewer.framePanel(identifier, handle, panel); > >>> + // Framing the panel needs to happen in a thread whose thread > >>> group > >>> + // is the same as the threadgroup of the applet thread. If this > >>> + // isn't the case, the awt eventqueue thread's context > >>> classloader > >>> + // won't be set to a JNLPClassLoader, and when an applet class > >>> needs > >>> + // to be loaded from the awt eventqueue, it won't be found. > >>> + Thread panelInit = new Thread(panel.getFutureTG(), new > >>> Runnable() > >>> { > >>> + @Override public void run() { > >>> + panel.createNewAppContext(); > >>> + // create the frame. > >>> + PluginAppletViewer.framePanel(identifier, handle, panel); > >>> + panel.init(); > >>> + // Start the applet > >>> + initEventQueue(panel); > >>> + } > >>> + }, "NetXPanel initializer"); > >>> > >>> - panel.init(); > >>> - > >>> - // Start the applet > >>> - initEventQueue(panel); > >>> + panelInit.start(); > >>> + while(panelInit.isAlive()) { > >>> + try { > >>> + panelInit.join(); > >>> + } catch (InterruptedException e) { > >>> + } > >>> + } > >>> > >> > >> This part looks fine to me, but I am not too familiar with the > >> concurrency requirements and communication between threads that > >> goes > >> on in PluginAppletViewer. > > > > This code is meant to be as close to the original as possible, with > > the > > exception that it should happen in the same TG as the one of the > > thread > > that will do the loading in panel.init() (and with a new AppContext > > so > > that we get new eventqueue threads for new applets). > > > > What do you think about the TODO? > > I think you suggested something like that to me yesterday. That's > > why > > I put the TODO in there. However, what we have now is what we've > > always > > had (as far as the TG name goes), and I wasn't sure I should change > > it. > > > > > Cheers, > Omair -------------- next part -------------- A non-text attachment was scrubbed... Name: awt-classloading.patch Type: text/x-patch Size: 16858 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110429/434cc0c4/awt-classloading.patch From omajid at redhat.com Fri Apr 29 13:40:01 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 16:40:01 -0400 Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <2038785587.1156149.1304108058321.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> References: <2038785587.1156149.1304108058321.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <4DBB2221.5030803@redhat.com> On 04/29/2011 04:14 PM, Denis Lila wrote: >> If it's a warning and it bothers you, I think we should fix the cause >> (thought that should be a separate patch), not merely suppress the >> warning. > > Ok. Although, I don't think we should "fix" it. Doing that would > involve inserting a serialVersionUID field, which we only need > if we wanted to serialize NetxPanel (which we don't). The > compiler generates one itself, so even if we were doing > serialization we might not need to introduce that field. > Not to mention that putting in that field even though we don't > serialize might confuse future readers. > Well, I am just objecting to the SupressWarning. If you think it should never be serialized, perhaps overriding writeObject and readObject and throwing NotSerializableException might be better - though it sounds like overkill to me. > >> No, I think it's fine for now. AFAIK, knowing the name of the thread >> group is not sufficient to create other threads in it. As long as >> other applets cant access/use these other threadgroups, we are fine. > > Hm... other applets can access these thread groups, but only if > they have the same uKey, and hence share a classloader. Is that ok? > Yeah, that's fine. They are after all, sharing classloaders. The patch looks fine to me. Cheers, Omair From dlila at redhat.com Fri Apr 29 13:53:09 2011 From: dlila at redhat.com (Denis Lila) Date: Fri, 29 Apr 2011 16:53:09 -0400 (EDT) Subject: [RFC][plugin]: Class loading problem. In-Reply-To: <4DBB2221.5030803@redhat.com> Message-ID: <1427638951.1156800.1304110389712.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> > Well, I am just objecting to the SupressWarning. If you think it > should > never be serialized, perhaps overriding writeObject and readObject and > throwing NotSerializableException might be better - though it sounds > like overkill to me. Definitely overkill. Ok, then I guess we leave it as it is. > Yeah, that's fine. They are after all, sharing classloaders. > > The patch looks fine to me. Nice. Thanks for the review. Regards, Denis. ----- Original Message ----- > On 04/29/2011 04:14 PM, Denis Lila wrote: > >> If it's a warning and it bothers you, I think we should fix the > >> cause > >> (thought that should be a separate patch), not merely suppress the > >> warning. > > > > Ok. Although, I don't think we should "fix" it. Doing that would > > involve inserting a serialVersionUID field, which we only need > > if we wanted to serialize NetxPanel (which we don't). The > > compiler generates one itself, so even if we were doing > > serialization we might not need to introduce that field. > > Not to mention that putting in that field even though we don't > > serialize might confuse future readers. > > > > > > > >> No, I think it's fine for now. AFAIK, knowing the name of the > >> thread > >> group is not sufficient to create other threads in it. As long as > >> other applets cant access/use these other threadgroups, we are > >> fine. > > > > Hm... other applets can access these thread groups, but only if > > they have the same uKey, and hence share a classloader. Is that ok? > > > > > Cheers, > Omair From omajid at redhat.com Fri Apr 29 13:56:51 2011 From: omajid at redhat.com (Omair Majid) Date: Fri, 29 Apr 2011 16:56:51 -0400 Subject: [icedtea-web] xml output for junit, transformation sheets for daily report In-Reply-To: <4DBA8360.5020403@redhat.com> References: <4DBA8360.5020403@redhat.com> Message-ID: <4DBB2613.5070000@redhat.com> On 04/29/2011 05:22 AM, Jiri Vanek wrote: > This patch add functionality to export xml report form junit testsuite, > provides some basic nice transformation for make xml fast readable and > navigation-able. Also add filtering of inner classes and jnlp from > tests-source package > > Pavel, is xml-content enough for you? > Looks like you forgot to attach the tests/junit-runner/XmlOutputListener.java file. The changes to CommandLine.java look fine to me, but I would like to see the rest of the patch ;) Is the xml schema based on an existing schema or is it completely new? Cheers, Omair From dlila at icedtea.classpath.org Fri Apr 29 14:02:10 2011 From: dlila at icedtea.classpath.org (dlila at icedtea.classpath.org) Date: Fri, 29 Apr 2011 21:02:10 +0000 Subject: /hg/icedtea-web: Fix appcontext related plugin bugs. Message-ID: changeset d57169ddb76a in /hg/icedtea-web details: http://icedtea.classpath.org/hg/icedtea-web?cmd=changeset;node=d57169ddb76a author: Denis Lila date: Fri Apr 29 16:58:05 2011 -0400 Fix appcontext related plugin bugs. diffstat: ChangeLog | 24 ++++ netx/net/sourceforge/jnlp/Launcher.java | 17 +- netx/net/sourceforge/jnlp/NetxPanel.java | 89 ++++++++++++--- netx/net/sourceforge/jnlp/PluginBridge.java | 32 +----- netx/net/sourceforge/jnlp/runtime/AppThreadGroup.java | 63 ----------- plugin/icedteanp/java/sun/applet/PluginAppletViewer.java | 36 ++++- 6 files changed, 129 insertions(+), 132 deletions(-) diffs (410 lines): diff -r a9729e1bb762 -r d57169ddb76a ChangeLog --- a/ChangeLog Thu Apr 28 16:23:11 2011 -0400 +++ b/ChangeLog Fri Apr 29 16:58:05 2011 -0400 @@ -1,3 +1,27 @@ +2011-04-28 Denis Lila + + * netx/net/sourceforge/jnlp/NetxPanel.java: + Remove unused import; add imports. + (uKey, uKeyToTG, appContextCreated): New members. + (getThreadGroup, createNewAppContext): New methods. + (runLoader): Pass uKey to PluginBridge's constructor. + (run): Remove. No longer needed. + (NetxPanel): Initialize uKey. If it is a new key, make a new thread + group for it and save it in the hash map. + (createAppletThread): Use getFutureTG instead of creating a thread + group on the spot. + * plugin/icedteanp/java/sun/applet/PluginAppletViewer.java: + (createPanel): Initialize and frame the panel in a separate thread. + * netx/net/sourceforge/jnlp/Launcher.java: + Remove unused import. + (createApplet, createApplication, createThreadGroup): Replace + AppThreadGroup with ThreadGroup. Remove all calls to setApplication. + * netx/net/sourceforge/jnlp/PluginBridge.java: + (PluginBridge): Remove the uniqueKey initialization logic. Set + uniqueKey to the uKey parameter. + * netx/net/sourceforge/jnlp/runtime/AppThreadGroup.java: + Remove file. + 2011-04-28 Omair Majid * Makefile.am (javaws, itweb_settings): New variables. diff -r a9729e1bb762 -r d57169ddb76a netx/net/sourceforge/jnlp/Launcher.java --- a/netx/net/sourceforge/jnlp/Launcher.java Thu Apr 28 16:23:11 2011 -0400 +++ b/netx/net/sourceforge/jnlp/Launcher.java Fri Apr 29 16:58:05 2011 -0400 @@ -32,7 +32,6 @@ import net.sourceforge.jnlp.cache.CacheUtil; import net.sourceforge.jnlp.cache.UpdatePolicy; -import net.sourceforge.jnlp.runtime.AppThreadGroup; import net.sourceforge.jnlp.runtime.AppletInstance; import net.sourceforge.jnlp.runtime.ApplicationInstance; import net.sourceforge.jnlp.runtime.JNLPClassLoader; @@ -702,7 +701,7 @@ throw new ClassNotFoundException("Can't do a codebase look up and there are no jars. Failing sooner rather than later"); } - AppThreadGroup group = (AppThreadGroup) Thread.currentThread().getThreadGroup(); + ThreadGroup group = Thread.currentThread().getThreadGroup(); String appletName = file.getApplet().getMainClass(); @@ -718,7 +717,6 @@ else appletInstance = new AppletInstance(file, group, loader, applet, cont); - group.setApplication(appletInstance); loader.setApplication(appletInstance); setContextClassLoaderForAllThreads(appletInstance.getThreadGroup(), appletInstance.getClassLoader()); @@ -765,10 +763,9 @@ protected ApplicationInstance createApplication(JNLPFile file) throws LaunchException { try { JNLPClassLoader loader = JNLPClassLoader.getInstance(file, updatePolicy); - AppThreadGroup group = (AppThreadGroup) Thread.currentThread().getThreadGroup(); + ThreadGroup group = Thread.currentThread().getThreadGroup(); ApplicationInstance app = new ApplicationInstance(file, group, loader); - group.setApplication(app); loader.setApplication(app); return app; @@ -784,16 +781,16 @@ * then this method simply returns the existing ThreadGroup. The applet * ThreadGroup has to be created at an earlier point in the applet code. */ - protected AppThreadGroup createThreadGroup(JNLPFile file) { - AppThreadGroup appThreadGroup = null; + protected ThreadGroup createThreadGroup(JNLPFile file) { + ThreadGroup tg = null; if (file instanceof PluginBridge) { - appThreadGroup = (AppThreadGroup) Thread.currentThread().getThreadGroup(); + tg = Thread.currentThread().getThreadGroup(); } else { - appThreadGroup = new AppThreadGroup(mainGroup, file.getTitle()); + tg = new ThreadGroup(mainGroup, file.getTitle()); } - return appThreadGroup; + return tg; } /** diff -r a9729e1bb762 -r d57169ddb76a netx/net/sourceforge/jnlp/NetxPanel.java --- a/netx/net/sourceforge/jnlp/NetxPanel.java Thu Apr 28 16:23:11 2011 -0400 +++ b/netx/net/sourceforge/jnlp/NetxPanel.java Fri Apr 29 16:58:05 2011 -0400 @@ -23,12 +23,13 @@ package net.sourceforge.jnlp; import net.sourceforge.jnlp.AppletLog; -import net.sourceforge.jnlp.runtime.AppThreadGroup; import net.sourceforge.jnlp.runtime.AppletInstance; import net.sourceforge.jnlp.runtime.JNLPRuntime; import java.net.URL; import java.util.Hashtable; +import java.util.concurrent.ConcurrentHashMap; +import java.util.concurrent.ConcurrentMap; import sun.applet.AppletViewerPanel; import sun.awt.SunToolkit; @@ -44,9 +45,58 @@ private boolean exitOnFailure = true; private AppletInstance appInst = null; private boolean appletAlive; + private final String uKey; + + // We use this so that we can create exactly one thread group + // for all panels with the same uKey. + private static final ConcurrentMap uKeyToTG = + new ConcurrentHashMap(); + + // This map is actually a set (unfortunately there is no ConcurrentSet + // in java.util.concurrent). If KEY is in this map, then we know that + // an app context has been created for the panel that has uKey.equals(KEY), + // so we avoid creating it a second time for panels with the same uKey. + // Because it's a set, only the keys matter. However, we can't insert + // null values in because if we did, we couldn't use null checks to see + // if a key was absent before a putIfAbsent. + private static final ConcurrentMap appContextCreated = + new ConcurrentHashMap(); public NetxPanel(URL documentURL, Hashtable atts) { super(documentURL, atts); + + /* According to http://download.oracle.com/javase/6/docs/technotes/guides/deployment/deployment-guide/applet-compatibility.html, + * classloaders are shared iff these properties match: + * codebase, cache_archive, java_archive, archive + * + * To achieve this, we create the uniquekey based on those 4 values, + * always in the same order. The initial "=" parts ensure a + * bad tag cannot trick the loader into getting shared with another. + */ + + // Firefox sometimes skips the codebase if it is default -- ".", + // so set it that way if absent + String codebaseAttr = atts.get("codebase") != null ? + atts.get("codebase") : "."; + + String cache_archiveAttr = atts.get("cache_archive") != null ? + atts.get("cache_archive") : ""; + + String java_archiveAttr = atts.get("java_archive") != null ? + atts.get("java_archive") : ""; + + String archiveAttr = atts.get("archive") != null ? + atts.get("archive") : ""; + + this.uKey = "codebase=" + codebaseAttr + + "cache_archive=" + cache_archiveAttr + + "java_archive=" + java_archiveAttr + + "archive=" + archiveAttr; + + // when this was being done (incorrectly) in Launcher, the call was + // new AppThreadGroup(mainGroup, file.getTitle()); + ThreadGroup tg = new ThreadGroup(Launcher.mainGroup, this.documentURL.toString()); + uKeyToTG.putIfAbsent(this.uKey, tg); } // overloaded constructor, called when initialized via plugin @@ -58,18 +108,6 @@ } @Override - public void run() { - /* - * create an AppContext for this thread associated with this particular - * plugin instance (which runs in a different thread group from the rest - * of the plugin). - */ - SunToolkit.createNewAppContext(); - - super.run(); - } - - @Override protected void showAppletException(Throwable t) { /* * Log any exceptions thrown while loading, initializing, starting, @@ -78,7 +116,7 @@ AppletLog.log(t); super.showAppletException(t); } - + //Overriding to use Netx classloader. You might need to relax visibility //in sun.applet.AppletPanel for runLoader(). protected void runLoader() { @@ -90,7 +128,7 @@ getCode(), getWidth(), getHeight(), - atts); + atts, uKey); doInit = true; dispatchAppletEvent(APPLET_LOADING, null); @@ -154,11 +192,7 @@ } } - // when this was being done (incorrectly) in Launcher, the call was - // new AppThreadGroup(mainGroup, file.getTitle()); - ThreadGroup tg = new AppThreadGroup(Launcher.mainGroup, - this.documentURL.toString()); - handler = new Thread(tg, this); + handler = new Thread(getThreadGroup(), this); handler.start(); } @@ -174,4 +208,19 @@ public boolean isAlive() { return handler != null && handler.isAlive() && this.appletAlive; } + + public ThreadGroup getThreadGroup() { + return uKeyToTG.get(uKey); + } + + public void createNewAppContext() { + if (Thread.currentThread().getThreadGroup() != getThreadGroup()) { + throw new RuntimeException("createNewAppContext called from the wrong thread."); + } + // only create a new context if one hasn't already been created for the + // applets with this unique key. + if (null == appContextCreated.putIfAbsent(uKey, Boolean.TRUE)) { + SunToolkit.createNewAppContext(); + } + } } diff -r a9729e1bb762 -r d57169ddb76a netx/net/sourceforge/jnlp/PluginBridge.java --- a/netx/net/sourceforge/jnlp/PluginBridge.java Thu Apr 28 16:23:11 2011 -0400 +++ b/netx/net/sourceforge/jnlp/PluginBridge.java Fri Apr 29 16:58:05 2011 -0400 @@ -44,7 +44,8 @@ private boolean codeBaseLookup; public PluginBridge(URL codebase, URL documentBase, String jar, String main, - int width, int height, Hashtable atts) + int width, int height, Hashtable atts, + String uKey) throws Exception { specVersion = new Version("1.0"); fileVersion = new Version("1.1"); @@ -132,34 +133,7 @@ else security = null; - /* According to http://download.oracle.com/javase/6/docs/technotes/guides/deployment/deployment-guide/applet-compatibility.html, - * classloaders are shared iff these properties match: - * codebase, cache_archive, java_archive, archive - * - * To achieve this, we create the uniquekey based on those 4 values, - * always in the same order. The initial "=" parts ensure a - * bad tag cannot trick the loader into getting shared with another. - */ - - // Firefox sometimes skips the codebase if it is default -- ".", - // so set it that way if absent - String codebaseAttr = atts.get("codebase") != null ? - atts.get("codebase") : "."; - - String cache_archiveAttr = atts.get("cache_archive") != null ? - atts.get("cache_archive") : ""; - - String java_archiveAttr = atts.get("java_archive") != null ? - atts.get("java_archive") : ""; - - String archiveAttr = atts.get("archive") != null ? - atts.get("archive") : ""; - - this.uniqueKey = "codebase=" + codebaseAttr + - "cache_archive=" + cache_archiveAttr + - "java_archive=" + java_archiveAttr + - "archive=" + archiveAttr; - + this.uniqueKey = uKey; usePack = false; useVersion = false; String jargs = atts.get("java_arguments"); diff -r a9729e1bb762 -r d57169ddb76a netx/net/sourceforge/jnlp/runtime/AppThreadGroup.java --- a/netx/net/sourceforge/jnlp/runtime/AppThreadGroup.java Thu Apr 28 16:23:11 2011 -0400 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,63 +0,0 @@ -// Copyright (C) 2001-2003 Jon A. Maxwell (JAM) -// -// This library is free software; you can redistribute it and/or -// modify it under the terms of the GNU Lesser General Public -// License as published by the Free Software Foundation; either -// version 2.1 of the License, or (at your option) any later version. -// -// This library is distributed in the hope that it will be useful, -// but WITHOUT ANY WARRANTY; without even the implied warranty of -// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU -// Lesser General Public License for more details. -// -// You should have received a copy of the GNU Lesser General Public -// License along with this library; if not, write to the Free Software -// Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. - -package net.sourceforge.jnlp.runtime; - -/** - * Thread group for a JNLP application. - * - * @author Jon A. Maxwell (JAM) - initial author - * @version $Revision: 1.5 $ - */ -public class AppThreadGroup extends ThreadGroup { - - /** the app */ - private ApplicationInstance app = null; - - /** - * Creates new JavaAppThreadGroup - * - * @param name of the App - */ - public AppThreadGroup(ThreadGroup parent, String name) { - super(parent, name); - } - - /** - * Sets the JNLP app this group is for; can only be called once. - */ - public void setApplication(ApplicationInstance app) { - if (this.app != null) - throw new IllegalStateException("Application can only be set once"); - - this.app = app; - } - - /** - * Returns the JNLP app for this thread group. - */ - public ApplicationInstance getApplication() { - return app; - } - - /** - * Handle uncaught exceptions for the app. - */ - public void uncaughtException(Thread t, Throwable e) { - super.uncaughtException(t, e); - } - -} diff -r a9729e1bb762 -r d57169ddb76a plugin/icedteanp/java/sun/applet/PluginAppletViewer.java --- a/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Thu Apr 28 16:23:11 2011 -0400 +++ b/plugin/icedteanp/java/sun/applet/PluginAppletViewer.java Fri Apr 29 16:58:05 2011 -0400 @@ -123,10 +123,10 @@ class PluginAppletPanelFactory { public AppletPanel createPanel(PluginStreamHandler streamhandler, - int identifier, - long handle, int x, int y, - final URL doc, - final Hashtable atts) { + final int identifier, + final long handle, int x, int y, + final URL doc, + final Hashtable atts) { final NetxPanel panel = AccessController.doPrivileged(new PrivilegedAction() { public NetxPanel run() { NetxPanel panel = new NetxPanel(doc, atts, false); @@ -136,13 +136,29 @@ } }); - // create the frame. - PluginAppletViewer.framePanel(identifier, handle, panel); + // Framing the panel needs to happen in a thread whose thread group + // is the same as the threadgroup of the applet thread. If this + // isn't the case, the awt eventqueue thread's context classloader + // won't be set to a JNLPClassLoader, and when an applet class needs + // to be loaded from the awt eventqueue, it won't be found. + Thread panelInit = new Thread(panel.getThreadGroup(), new Runnable() { + @Override public void run() { + panel.createNewAppContext(); + // create the frame. + PluginAppletViewer.framePanel(identifier, handle, panel); + panel.init(); + // Start the applet + initEventQueue(panel); + } + }, "NetXPanel initializer"); - panel.init(); - - // Start the applet - initEventQueue(panel); + panelInit.start(); + while(panelInit.isAlive()) { + try { + panelInit.join(); + } catch (InterruptedException e) { + } + } // Wait for the panel to initialize PluginAppletViewer.waitForAppletInit(panel); From ahughes at redhat.com Fri Apr 29 16:24:27 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Sat, 30 Apr 2011 00:24:27 +0100 Subject: RFC: Port libpng1.5 support to icedtea7 In-Reply-To: <4DBAF1BC.1090409@redhat.com> References: <4DBAE689.4070900@redhat.com> <4DBAF1BC.1090409@redhat.com> Message-ID: <20110429232427.GA3016@rivendell.middle-earth.co.uk> On 13:13 Fri 29 Apr , Omair Majid wrote: > On 04/29/2011 12:25 PM, Omair Majid wrote: > > Hi, > > > > The attached patch for icedtea7 forest (jdk repo) adds support for > > building with libpng 1.5. It is based on the g356743-libpng-1.5.patch > > file in icedtea6. > > > > Okay to commit? > > > > Just realized that this patch was originally written by Alexis Ballier > who has not signed the SCA. Is it ok to add such a patch to the icedtea > forest at hg.openjdk.java.net? Or should this be a local patch in > icedtea.classpath.org/hg/icedtea ? > It's fine. I'm thinking of moving the forest to the IcedTea servers anyway to allow easier access. Please commit. > Thanks, > Omair -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Fri Apr 29 16:27:18 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Sat, 30 Apr 2011 00:27:18 +0100 Subject: [icedtea-web] xml output for junit, transformation sheets for daily report In-Reply-To: <4DBA8360.5020403@redhat.com> References: <4DBA8360.5020403@redhat.com> Message-ID: <20110429232718.GB3016@rivendell.middle-earth.co.uk> On 11:22 Fri 29 Apr , Jiri Vanek wrote: > This patch add functionality to export xml report form junit testsuite, > provides some basic nice transformation for make xml fast readable and > navigation-able. Also add filtering of inner classes and jnlp from > tests-source package > > Pavel, is xml-content enough for you? > > Regards J. The patch isn't complete. Did you forget to hg add? -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From ahughes at redhat.com Fri Apr 29 18:08:05 2011 From: ahughes at redhat.com (Dr Andrew John Hughes) Date: Sat, 30 Apr 2011 02:08:05 +0100 Subject: RFC: backport S6986968: Crash on XIM server restart In-Reply-To: <4D77E579.3060505@redhat.com> References: <4D77E579.3060505@redhat.com> Message-ID: <20110430010805.GD3016@rivendell.middle-earth.co.uk> On 15:39 Wed 09 Mar , Omair Majid wrote: > Hi, > > I would like to backport S6986968 which fixes a crash that happens > whenever the XIM server (for example, iBus) restarts while the java > application has focus. > > Okay to commit? > > Cheers, > Omair Ok by me. > diff -r 4cbe17b91cc8 ChangeLog > --- a/ChangeLog Wed Mar 09 10:50:40 2011 +0100 > +++ b/ChangeLog Wed Mar 09 15:38:30 2011 -0500 > @@ -1,3 +1,8 @@ > +2011-03-09 Omair Majid > + > + * Makefile.am (ICEDTEA_PATCHES): Add new patch. > + * patches/openjdk/6986968-crash_on_xim_restart.patch: New file. > + > 2011-03-09 Pavel Tisnovsky > > * Makefile.am: Add new patch. > diff -r 4cbe17b91cc8 Makefile.am > --- a/Makefile.am Wed Mar 09 10:50:40 2011 +0100 > +++ b/Makefile.am Wed Mar 09 15:38:30 2011 -0500 > @@ -326,7 +326,8 @@ > patches/openjdk/6934977-MappedByteBuffer.load.patch \ > patches/jaxp-serial-version-uid.patch \ > patches/jtreg-hotspot-bug-6196102.patch \ > - patches/jtreg-double-to-string.patch > + patches/jtreg-double-to-string.patch \ > + patches/openjdk/6986968-crash_on_xim_restart.patch > > if WITH_ALT_HSBUILD > ICEDTEA_PATCHES += \ > diff -r 4cbe17b91cc8 patches/openjdk/6986968-crash_on_xim_restart.patch > --- /dev/null Thu Jan 01 00:00:00 1970 +0000 > +++ b/patches/openjdk/6986968-crash_on_xim_restart.patch Wed Mar 09 15:38:30 2011 -0500 > @@ -0,0 +1,23 @@ > +# HG changeset patch > +# User omajid > +# Date 1285601403 14400 > +# Node ID bbadb9484f537ce1e6ecf6e0d1f130235367c7e4 > +# Parent 278c8daa30750577cadb47f7c6c827d2dfb7d0bd > +6986968: Crash on XIM server restart > +Summary: Free XIM data structures on DestroyXIMCallback > +Reviewed-by: naoto > + > +diff -r 278c8daa3075 -r bbadb9484f53 src/solaris/native/sun/awt/awt_InputMethod.c > +--- openjdk/jdk/src/solaris/native/sun/awt/awt_InputMethod.c Mon Sep 27 13:38:49 2010 +0400 > ++++ openjdk/jdk/src/solaris/native/sun/awt/awt_InputMethod.c Mon Sep 27 11:30:03 2010 -0400 > +@@ -1473,6 +1473,10 @@ > + static void DestroyXIMCallback(XIM im, XPointer client_data, XPointer call_data) { > + /* mark that XIM server was destroyed */ > + X11im = NULL; > ++ JNIEnv* env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2); > ++ /* free the old pX11IMData and set it to null. this also avoids crashing > ++ * the jvm if the XIM server reappears */ > ++ X11InputMethodData *pX11IMData = getX11InputMethodData(env, currentX11InputMethodInstance); > + } > + > + /* -- Andrew :) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and IcedTea http://www.gnu.org/software/classpath http://icedtea.classpath.org PGP Key: F5862A37 (https://keys.indymedia.org/) Fingerprint = EA30 D855 D50F 90CD F54D 0698 0713 C3ED F586 2A37 From jvanek at redhat.com Sat Apr 30 06:26:48 2011 From: jvanek at redhat.com (Jiri Vanek) Date: Sat, 30 Apr 2011 15:26:48 +0200 Subject: [icedtea-web] xml output for junit, transformation sheets for daily report In-Reply-To: <4DBB2613.5070000@redhat.com> References: <4DBA8360.5020403@redhat.com> <4DBB2613.5070000@redhat.com> Message-ID: <4DBC0E18.1060803@redhat.com> On 04/29/2011 10:56 PM, Omair Majid wrote: > On 04/29/2011 05:22 AM, Jiri Vanek wrote: >> This patch add functionality to export xml report form junit testsuite, >> provides some basic nice transformation for make xml fast readable and >> navigation-able. Also add filtering of inner classes and jnlp from >> tests-source package >> >> Pavel, is xml-content enough for you? >> > > Looks like you forgot to attach the > tests/junit-runner/XmlOutputListener.java file. The changes to > CommandLine.java look fine to me, but I would like to see the rest of > the patch ;) > > Is the xml schema based on an existing schema or is it completely new? > No. it is minimalistic to our purposes. Should follow junit ant-xml output? Or some else? > Cheers, > Omair > > The patch isn't complete. Did you forget to hg add? > >-- >Andrew :) To much true! fixed patch added -------------- next part -------------- A non-text attachment was scrubbed... Name: tests-xml-output-complete.patch Type: text/x-patch Size: 19436 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20110430/3b100518/tests-xml-output-complete.patch