Alan Bateman (Comments) 2011-03-15T11:01:09+00:00 Apache Roller Re: file paths and file URIs Edward Wang 2010-12-03T02:00:32+00:00 2010-12-03T02:00:32+00:00 <p>Finally! Well done.</p> Re: Meanwhile, back at the ranch Dusty 2010-11-11T05:32:56+00:00 2010-11-11T05:32:56+00:00 <p>My previous post has been lost, I was saying that a very basic bug on the JVM has been reported 6 years ago, the cause was found, but it's still unfixed..</p> <p>Alan, can you, working at Oracle, raise the attention on it?</p> <p>Thanks!</p> Re: Meanwhile, back at the ranch Dusty 2010-11-10T06:16:19+00:00 2010-11-10T06:16:19+00:00 <p>Here is the relevant bug report, opened more than 6 (SIX!) years ago:</p> <p><a href="" rel="nofollow"></a></p> <p>:(</p> Re: IPv6 Vladimir Kotal 2010-11-10T03:03:38+00:00 2010-11-10T03:03:38+00:00 <p>IPv6 gaining traction also mentioned here: <a href="" rel="nofollow"></a></p> Re: IPv6 Rémi Forax 2010-11-10T03:01:40+00:00 2010-11-10T03:01:40+00:00 <p>There is a script that predicts the depletion of IPv4 addresses: <br/> <a href="" rel="nofollow"></a></p> Re: IPv6 joakime 2010-11-09T13:01:21+00:00 2010-11-09T13:01:21+00:00 <p>RE: "Sudden Interest"</p> <p>The complete depletion of IPv4 addresses is near.<br/> It is estimated by some to occur within the next 200 odd days.<br/> Others say early 2011.</p> <p><a href="" rel="nofollow"></a></p> <p>There is a strong push by folks that plan ahead to start embracing and supporting IPv6 now, to learn it, to use it.</p> Re: Meanwhile, back at the ranch Mark Wielaard 2010-11-05T04:54:29+00:00 2010-11-05T04:54:29+00:00 <p>Sure, you still have some proprietary blobs. But you can just use the GPL+exception for all the OpenJDK code. Only your proprietary add ons need to be covered by a closed license (thanks to the assembly exception). That way people would actually get the freedom to inspect the OpenJDK parts themselves and see what is different from the community builds. The current draconian proprietary license you are using basically forbids community members to inspect the free shared code. Using a license that forbids sending feedback to the OpenJDK communtiy really is not nice and unfair to all who contributed to the code.</p> Re: Meanwhile, back at the ranch Alan Bateman 2010-11-05T04:21:05+00:00 2010-11-05T04:21:05+00:00 <p>I guess you know this already, but Oracle's binaries get built with some proprietary components such as the plug-in, web start, installers. Creating binaries from the OpenJDK repos would be nice but I personally don't have cycles to do that. In any case, this entry wasn't meant to highlight that hoary issue. Rather it's to coax developers into trying JDK 7 and sending feedback so that bugs/issues are caught as early as possible. JDK 7 might not be a large release (relatively speaking), but there are still several truck load of changes.</p> Re: Meanwhile, back at the ranch Mark Wielaard 2010-11-04T10:06:44+00:00 2010-11-04T10:06:44+00:00 <p>Hi Alan,</p> <p>Since you point to the OpenJDK 7 feature list I assume these JDK 7 snapshots are derived from the OpenJDK sources. Could you post them under a more friendly license, preferably just GPL like the rest of us are using?</p> <p>I tried to use them to compare to my own builds, but apparently the license doesn't allow me to :{ Error: License was not accepted.</p> <p>This was the same issue pointed out some time ago:<br/> <a href="" rel="nofollow"></a></p> <p>Then Mark Reinhold actually published his builds under the GPL:<br/> <a href="" rel="nofollow"></a></p> <p>Could you please do the same?</p> <p>Thanks,</p> <p>Mark</p> Re: Is the JDK losing its edge(s)? Alan 2009-12-28T13:19:50+00:00 2009-12-28T13:19:50+00:00 <p>Micah: jsr223 and jsr292 aren't currently in our base module.</p> <p>John: I'd suggest bringing up your question on nio-dev as it's off-topic here. </p> <p>Endre: No, I meant that the no-op test will likely ~300 classes (not >500 as suggested).</p> Re: Is the JDK losing its edge(s)? Endre Stølsvik 2009-12-26T17:09:20+00:00 2009-12-26T17:09:20+00:00 <p>@Alan: "the number of classes loaded for the empty main case should be ~300."</p> <p>Oops, I think there might have snuck in two zeros in that string; You probably meant ~3? String, Object, and the class in question?</p> Re: Is the JDK losing its edge(s)? John Davis 2009-12-26T06:19:56+00:00 2009-12-26T06:19:56+00:00 <p>When will the NIO api be updated to take advantage of GetQueuedCompletionStatusEx on 2008 Server?</p> Re: Is the JDK losing its edge(s)? Micah J 2009-12-25T13:46:16+00:00 2009-12-25T13:46:16+00:00 <p>Would the base module include support for JSR 233 and 292? I'm wondering if the new light weight Java VM wouldn't be a very good candidate for creating a cross platform/cross browser JavaScript engine.</p> <p>While there are quite a few good entrants in this race: WebKit's SquirrelFish Extreme, Google's V8, Mozilla's TraceMonkey, and Opera's Carakan; I would suggest that the race is far from over yet.</p> <p>I think an argument could be made that a more memory efficient and performant JVM for dynamic languages that can go anywhere would be very valuable to the browser platform makers targeting a consistent development experience for desktops, netbooks, and moble devices.</p> Re: Is the JDK losing its edge(s)? Alan 2009-12-17T07:11:09+00:00 2009-12-17T07:11:09+00:00 <p>Jesse: we definitely want to learn from other projects although we have to be very careful not to break compatibility. I think the only think we've broken so far is support for jdk1.1 style security policy files. API dependencies are the most problematic. You mentioned Beans but that's not too bad in that the remaining dependencies are in implementation code (not API signatures) so there is potential to separate it into its own module. We don't have any plans to do load-time transformations. If we did then it could be done statically to avoid the runtime cost. The build and layout in the repository will need to attacked at some point but for now we're focused more on the runtime. </p> <p>Patrick: the number of classes loaded for the empty main case should be ~300.</p> <p>Michael: Thanks for the link. In our module definitions (all very tentative at this point) you'll see there is Xerces and Xalan modules, in addition to the API module. This might be interesting to your work.</p> Re: Is the JDK losing its edge(s)? Michael Kay 2009-12-17T02:34:58+00:00 2009-12-17T02:34:58+00:00 <p>I did some work analyzing the dependencies mainly in the XML area, reported here:</p> <p><a href="" rel="nofollow"></a></p> <p>which may be of interest. A few small changes can help a lot. (In the end, though, I shipped with the Apache Xerces parser rather than the one from the JDK, partly because it was easier to extricate, but more importantly because it is much more reliable and conformant.)</p> Re: Is the JDK losing its edge(s)? Patrick Wright 2009-12-15T14:44:26+00:00 2009-12-15T14:44:26+00:00 <p>A plain Java class with only an empty main() defined causes 545 classes to be loaded (java -verbose:class). Seems like there is room for improvement; am glad that you all are working on it.</p> Re: Is the JDK losing its edge(s)? Rick Minerich 2009-12-15T06:31:40+00:00 2009-12-15T06:31:40+00:00 <p>How about removing those nasty yahoo toolbar dependencies while you're at it?</p> Re: Is the JDK losing its edge(s)? Lachlan O'Dea 2009-12-14T17:42:14+00:00 2009-12-14T17:42:14+00:00 <p>This is great work.</p> <p>With regard to: "We've also got many classes in sun.misc that aren't used anymore but we can't remove them because there may be naughty applications out there using them directly"</p> <p>Surely this support doesn't need to be maintained? Considering that the documentation and the compiler have scary warnings about the dangers of using sun.misc. It was always explicit that it was not a supported part of the platform.</p> Re: Is the JDK losing its edge(s)? Jesse Glick 2009-12-14T10:41:20+00:00 2009-12-14T10:41:20+00:00 <p>Sounds very similar to dependency refactoring we undertook in the NetBeans Platform, especially cca. 2003-2005.</p> <p>Fixing dependencies without breaking compatibility of published APIs is unfortunately very hard in a statically typed language with closed classes like Java, since dependencies may be physically mentioned in public signatures. For a while we resorted to bytecode postprocessing tricks to maintain a degree of binary compatibility while refactoring sources, but this proved difficult to maintain and eventually we just decided to break binary compatibility for some of the oldest APIs. What would have made the job far easier is some way of expressing bytecode-level transformations of clients, to be interpreted by class loaders. For example, say you could remove java.awt.Image getIcon(int) from BeanInfo yet somehow place an annotation on the BeanInfo class declaration indicating that an interface exists in the java.awt module defining this method, together with some adapter providing implementations. Existing clients which called myBeanInfo.getIcon(myType) could be rewired during class loading to call something like sun.reflect.Rewire.invoke(BeanInfo.class, "Ljava/awt/Image;getIcon(I)", myBeanInfo, muType) which would somehow look up the right implementation in java.awt and call it, without requiring the java.beans module to have either a compile-time or link-time dependency on java.awt. (<a href="" rel="nofollow"></a> is a somewhat analogous tool for source transformations.)</p> <p>One thing we continue to do is to apply load-time transformations to module dependency declarations (as opposed to class "imports" in bytecode). The primary purpose is to deprecate part of a published API (at class granularity) and split it off into a deprecated module. Old client modules will then get an implied dependency on the deprecated module, while new clients know to be free of deprecated dependencies can skip loading it. Format: <a href="" rel="nofollow"></a></p> <p>By the way, do you plan as part of the separation to physically divide JDK sources (mainly jdk/src/share/classes) into separate source roots according to module membership? This is the clearest way to enforce good dependencies and ensure that developers think from the beginning about where a piece of code belongs, rather than problems being flagged only in a late packaging step. It is also friendliest to IDEs.</p> Re: Is the JDK losing its edge(s)? Alan 2009-12-14T07:56:04+00:00 2009-12-14T07:56:04+00:00 <p>Neal: you are right that startup is another area. It will require optimizations at module installation or configuration time and changes to get faster loading.</p> Re: Is the JDK losing its edge(s)? Carl Antaki 2009-12-14T07:52:46+00:00 2009-12-14T07:52:46+00:00 <p>Even though the JVM only loads the required classes as what can be seen with -verbose, RT.jar is 43MB which means that the JVM has to load this large file which takes time.</p> Re: Is the JDK losing its edge(s)? paulo 2009-12-14T07:15:32+00:00 2009-12-14T07:15:32+00:00 <p>Yes. Reducing start-up time requires more efficient classloading - this might actually increase the time, or is that my impression?</p> Re: Is the JDK losing its edge(s)? Neal Gafter 2009-12-13T16:41:56+00:00 2009-12-13T16:41:56+00:00 <p>I can see how this will reduce the (one-time) download time of the platform, but I don't see how it improves startup time. The VM today doesn't load classes that aren't actually used.</p> Re: Is the JDK losing its edge(s)? Endre Stølsvik 2009-12-13T15:33:48+00:00 2009-12-13T15:33:48+00:00 <p>I just love this - keep up the good work!</p> <p>I so hope for the JVM to become as small and have as fast startup as the Flash runtime. If the notion of running a small systray application in a JVM becomes something else than a complete absurdity, I think "java on the desktop" could at last become a real and actual concept.</p> <p>PS, on a tangent: A "do a full GC, full compaction incl. shedding of SoftRefs, then release it all back to the OS and shrink the footprint to this absolute minimal size" method would do heaps of good in regard to java on the desktop: An application could invoke this gcAndMemoryCompaction() method after so and so many seconds of inactivity (by some app-specific plausible not-in-use logic), or on "minimize to tray" or similar - to play nice with the rest of the OS and hence the user. It would also make the JVM slightly less hostile to swapping.</p> <p>This post is interesting, and I asked some similar questions in the comment section:<br/> <a href="" rel="nofollow"></a></p> Re: Is the JDK losing its edge(s)? uberVU - social comments 2009-12-13T12:49:12+00:00 2009-12-13T12:49:12+00:00 [Trackback] This post was mentioned on Twitter by pholdings: alan bateman on jdk modularity: Re: Is the JDK losing its edge(s)? Michael Nischt 2009-12-13T08:35:28+00:00 2009-12-13T08:35:28+00:00 <p>Thanks for sharing the information on the progress!</p> <p>I really think that the interdependencies of the JDK packages is the biggest argument against using the Java Platform. Nobody wants a monolithic architecture when it comes to software. </p> <p>I guess, in a perfect world we would have 'modules' with 'extensions', e.g.:</p> <p>logging.nio, logging.jmx (or better jmx.logging?)<br/> beans.awt, beans.swing, beans.jdbc (or awt.beans, .. )</p> <p>Unfortunately, this would lead to a namespace explosion but can hopefully be solved with jdk7's module language extensions.</p> <p>P.S. Also glad to hear that even interface changes are acceptable for the greater good.</p> Re: Sockets Direct Protocol network marketing 2009-05-21T01:47:32+00:00 2009-05-21T01:47:32+00:00 <p>thanks adminn:)</p> Re: Monitoring direct buffers Mandy Chung's Blog 2009-05-20T16:58:18+00:00 2009-05-20T16:58:18+00:00 [Trackback] "Monitoring and Troubleshooting Java applications with JDK tools" BOF at JavaOne 2009 Re: IO, NIO, It's Off to JavaOne 2009 We Go Leonardo 2009-04-18T14:52:01+00:00 2009-04-18T14:52:01+00:00 <p>I like that you post the BOF after JavaOne because I am a student and I like to read the BOF, but this is not public in the sun site.</p> <p>Thank you.</p> Re: JSR-203/NIO2 update Ismael Juma 2009-04-16T07:47:41+00:00 2009-04-16T07:47:41+00:00 <p>Hi Richard,</p> <p>Memory mapping files is useful in certain situations and 2GB is not particularly large these days (and even less in 2010 when JDK7 will be released).</p> <p>If streaming is the way forward, why does Java even support memory mapping of files?</p> <p>Best,<br/> Ismael</p>