[The Java Posse] Re: there once was a language called scala
I hope you write better code than poetry! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Nice comparisons of language on the JVM
I did not see this discuss in here, and I really liked this quick overview of hoe the different languages looks like. Quoted from Brian Frank on http://www.fandev.org/sidewalk/topic/625 : Michael Galpin of eBay gave a talk at JavaOne on performance of various JVM languages. It is kind of interesting because you can compare a couple short programs implemented in Java, JRuby, Groovy, Jython, Clojure, Scala, and Fan all side by side. Fan's performance is quite good (better than Java on the word sort). You can see the presentation: http://fupeg.blogspot.com/2009/06/javaone-talk-performance-comparisons-of.html on his blog. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
Jesse, Actually I agree with you, the support for multiple JAR versions in OSGi is useful but not the most important feature. It's easy to forget that OSGi itself has only supported this feature since Release 4, i.e. since around 2004. Interestingly, the lack of multiple version support in OSGi Release 3 and earlier was highlighted by the original specification request for JSR 277. It was argued by Sun in 2005 that OSGi was not an acceptable solution for modularity because it did not support multiple versions of libraries, even though it already did by that time, and they are now seeking to design a new module system that also does not support multiple versions. Regards Neil On Jun 29, 4:21 am, Jess Holle je...@ptc.com wrote: Augusto wrote: On Jun 28, 6:38 pm, Steve stephen.a.lind...@gmail.com wrote: If an alternative modularity platform for app developers was more compelling than OSGi I certainly would jump ship, but it would need to at least provide what the OSGi core does now (proper component encapsulation, supporting multiple versions of the same 3rd party jar, runtime dynamism, etc.). Multiple versions of the same jar is one thing I described in my blog post incorrectly. Well, I said that was a core problem solved by a module system but in fact Jigsaw doesn't seem to support it. It is not needed for modularizing the JDK, but it is essential for modularizing applications. It is essential for /some/ applications. Personally I generally prefer to make all the parties involved work /really/ hard at allowing for and arriving at a single version of any given library (ideally the latest stable version) to be used at runtime rather than allowing multiple versions within an application. Using multiple library versions in one application is pretty much a worst case scenario to me -- and is generally a strong indication that someone is not keeping their software up-to-date (i.e. so that it can use the latest stable versions of the libraries it depends on). If that someone is a vendor or 3rd-party component then that's generally a sign to go shopping for another one -- unless, of course, you're the one who has been foolish enough to stay on an old version of that component instead of moving to the new version, in which case it is time to upgrade. -- Jess Holle P.S. If you mean multiple versions just for things like a web app reload, that's a different matter entirely, of course. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Regulators extend review of Oracle's Sun takeover
Dan Wall? Any relation...? On Jun 28, 5:48 am, Steven Herod steven.he...@gmail.com wrote: http://news.smh.com.au/breaking-news-technology/regulators-extend-rev... June 28, 2009 - 5:35AM The Department of Justice wants more information about Oracle Corp.'s planned takeover of computer server maker Sun Microsystems Inc., extending the agency's review of the $7.4 billion deal. Software maker Oracle said in a statement Friday that the Justice Department has extended its initial 30-day review period to seek additional information. The government's questions focus on the licensing of Java, the programming language developed by Sun that runs on more than 1 billion devices around the world. Oracle counsel Dan Wall said the issue is never going to get in the way of the deal. I fully expect that the investigation will end soon and not delay the closing of the deal this summer, said Wall, an attorney with Latham Watkins. Wall Street analysts expect the deal to close by summer's end. The transaction was not expected to face antitrust objections because the companies have very little overlap. Following the deal's close, Redwood Shores, Calif.-based Oracle will have the resources for its own one-stop technology shop, similar to IBM and Hewlett-Packard, to sell services, software and hardware. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: I love the posse
Can't we just make the interviews a little more like this: http://www.youtube.com/watch?v=bs1lKPdNfQ8 ? 2009/6/29 Michael Neale michael.ne...@gmail.com I agree with your sentiments - its an important debate, but I guess a podcast is not the place for it. So perhaps should be left to the thunderdome: 2 technologies enter, only 1 leaves type scenario ;) I also note Dick sounded very stressed in the episode, was an unusual one... On Jun 29, 11:03 am, Alan Kent alan.j.k...@saic.com wrote: Dear Posse, I love and continue to love the show and really appreciate all the hard work you guys put in, completely voluntarily. Its my #1 podcast. To Dick (Groovy) Wall, if you feel that ignoring JigSaw and OSGI keep you more motivated and enjoying doing the podcast, then go for it. Add them to your spam filters! The fact that the posse enjoy what you do I think is one of the things that makes the show so enjoyable to listen to. Its great! I love it! Keep it coming! I found both the OSGI and JigSaw interviews interesting - thanks for doing them. But I also found it interesting that from the interviews neither came out as being a clearly superior replacement of the other. I suspect this means that longer, deeper articles are required to delve into the topic - not something you would get on a podcast due to its format. It has always seemed to me their primary value propositions are different: OSGI value is it allows code to be dynamically loaded at run time, and JigSaw is tackling breaking up the JVM and includes compile time changes to support modules too. But frankly, as a long time podcast listener, I don't care that some feel JigSaw should not exist and OSGI should rule the world. Both *are* going to exist no matter what is said on this list. So to me further discussion along those lines is boring and a complete waste of time. I am more interested to learn more over time how the technical merits of one or the other solve real problems. So Dick, I would personally consider it a great *favor* if you ignored that sort of content on the podcast. Oh, I have added another email address to my spam filter as not contributing any technical value to some of the great conversations on this list. Alan --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Package by feature or layer?
On Jun 13, 1:15 pm, Christian Beil christian.a.b...@gmail.com wrote: What is your opinion on that? I'm especially interested in what you think about structuring packages? Do youpackageby layer (ie dao,service,controller,...) or do youpackagebyfeature? I think the IDE should let you tag stuff, so you can use the view that makes the most sense for whatever it is you are doing. So the packages could be by feature, but you could use the Controller, Repository, Service, etc. tag to view things in layers. Maybe the tags could even be derived directly from EJB3 or Spring annotations. This is kind of like the where should private methods go? debate: at the end of the file, or close to where they are used? If the IDE could give you a view that gives a good view of the method and the methods it uses, this wouldn't be an issue. Mwanji --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: there once was a language called scala
hehe :-) this is funny :-) On Jun 29, 7:40 am, Christian Catchpole christ...@catchpole.net wrote: there once was a language called Scala that promised the recursive leaps of the impala but when reduced to byte code it's tail couldn't handle the load and trampolines much more like a koala --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Nice comparisons of language on the JVM
On Mon, Jun 29, 2009 at 8:55 AM, Frederic Simon frederic.si...@gmail.comwrote: I did not see this discuss in here, and I really liked this quick overview of hoe the different languages looks like. Quoted from Brian Frank on http://www.fandev.org/sidewalk/topic/625 : Michael Galpin of eBay gave a talk at JavaOne on performance of various JVM languages. It is kind of interesting because you can compare a couple short programs implemented in Java, JRuby, Groovy, Jython, Clojure, Scala, and Fan all side by side. Fan's performance is quite good (better than Java on the word sort). You can see the presentation: http://fupeg.blogspot.com/2009/06/javaone-talk-performance-comparisons-of.html on his blog. I lost intrest at _The_ critical factor when choosing JVM language. SPEED Speed of what? Execution? Coding? WHAT?! The most important factor might _vary_ according to the needs of the client?! Argh... Ok. I'm done whining. -- Viktor Klang Scala Loudmouth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Nice comparisons of language on the JVM
On Mon, Jun 29, 2009 at 12:50 PM, Viktor Klang viktor.kl...@gmail.comwrote: On Mon, Jun 29, 2009 at 8:55 AM, Frederic Simon frederic.si...@gmail.comwrote: I did not see this discuss in here, and I really liked this quick overview of hoe the different languages looks like. Quoted from Brian Frank on http://www.fandev.org/sidewalk/topic/625 : Michael Galpin of eBay gave a talk at JavaOne on performance of various JVM languages. It is kind of interesting because you can compare a couple short programs implemented in Java, JRuby, Groovy, Jython, Clojure, Scala, and Fan all side by side. Fan's performance is quite good (better than Java on the word sort). You can see the presentation: http://fupeg.blogspot.com/2009/06/javaone-talk-performance-comparisons-of.html on his blog. I lost intrest at _The_ critical factor when choosing JVM language. SPEED Speed of what? Execution? Coding? WHAT?! The most important factor might _vary_ according to the needs of the client?! Argh... Ok. I'm done whining. Yes. I was just trying to be ADD funny. Nevermind. Move along. -- Viktor Klang Scala Loudmouth -- Viktor Klang Scala Loudmouth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: there once was a language called scala
well, there isn't too much that rhymes with scala :) On Jun 29, 7:36 pm, pantsula cklopp...@gmail.com wrote: hehe :-) this is funny :-) On Jun 29, 7:40 am, Christian Catchpole christ...@catchpole.net wrote: there once was a language called Scala that promised the recursive leaps of the impala but when reduced to byte code it's tail couldn't handle the load and trampolines much more like a koala --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: there once was a language called scala
On Jun 29, 8:33 am, Vince O'Sullivan vjosulli...@gmail.com wrote: I hope you write better code than poetry! I liked it. I think a trampolining koala and a recursively leaping impala are great images. Certainly, they are comforting when confronted with (_ + _) or some such. Mwanji --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 12:27 pm, Augusto augusto.sellh...@gmail.com wrote: No I mean that exactly. I don't know, I mean the point of modularizing something for me is I may want to use your module but I don't care about its internals. Or at most, I don't want the internals of your module to affect me. [disclaimer: I contribute to OSGi projects and I'm co-authoring a book on OSGi] exactly, that's why libraries often use tools to embed/repackage dependencies: http://maven.apache.org/plugins/maven-shade-plugin/ http://code.google.com/p/jarjar/ for example Guice has CGLIB and Google-Collections as internal dependencies, but I wouldn't want to be forced to use the same version of these libraries when using Guice - similarly the Guice team probably doesn't want to be bothered with problems caused by someone putting a different version of CGLIB before Guice on the classpath (the JVM will pick the first matching class when scanning the classpath, so ordering makes a big difference when there's overlapping content) so Guice repackages CGLIB and Google-Collections inside the jar - unfortunately this means anyone who already has those jars gets duplicate content (~400k?) now imagine if everyone does the same - you could end up with ten copies of the Google-Collection classes, embedded inside various libraries - you can already see this happening in applications today, and it's caused by a lack of modularity if there was a standard modularity system that supported multiple versions then the Guice team could distribute just their classes (plus the necessary metadata) safe in the knowledge that regardless of what jars were on the 'module' path, the right version would be wired to Guice that's one of the reasons why I find module systems compelling - now I can totally understand why you might need a special framework to modularize the JVM, just like the JVM has the Unsafe class for internal use - but I'm a little bit wary about using the same solution for applications, exactly because it might be optimized for the JVM (for example the no multiple versions requirement) still hoping that JSR 294 will help bring both sides together in some way... oh well, time will tell - I'd hate for people to be put off the general idea of modularity (and to some extent programming to interfaces) as imho it does lead to better apps -- Cheers, Stuart PS. many thanks to the JavaPosse for doing both of the interviews in the first place So yeah, you can expect your 3rd party libraries to keep up with the latest and greatest, but that's kind of an unreasonable expectation with fast paced technology. What I want is to use your library, but not have it affect the same libraries it might be using internally but that I explicitly depend on. BTW, when people say classpath hell (or jar hell) this is one of the main scenarios they refer to. http://c2.com/cgi/wiki?ClasspathHell -- One big need for OsGi / JavaModuleSystem? (JSR 277) functionality is to fix the ClasspathHell problem: * My application uses libraries B and C, both of which use library D. * But B and C require different versions of D. * There's no version of D I can put on the CLASSPATH that will satisfy both B and C. * Thus, I'm in ClasspathHell -- there's no standard Java way to fix the problem. I assume that the whole Application Context in Jigsaw means that for webapps and apps running in an EJB container you can overcome this but no I meant it more in a regular application outside of any of these containers. Augusto On Jun 28, 11:21 pm, Jess Holle je...@ptc.com wrote: Augusto wrote: On Jun 28, 6:38 pm, Steve stephen.a.lind...@gmail.com wrote: If an alternative modularity platform for app developers was more compelling than OSGi I certainly would jump ship, but it would need to at least provide what the OSGi core does now (proper component encapsulation, supporting multiple versions of the same 3rd party jar, runtime dynamism, etc.). Multiple versions of the same jar is one thing I described in my blog post incorrectly. Well, I said that was a core problem solved by a module system but in fact Jigsaw doesn't seem to support it. It is not needed for modularizing the JDK, but it is essential for modularizing applications. It is essential for /some/ applications. Personally I generally prefer to make all the parties involved work /really/ hard at allowing for and arriving at a single version of any given library (ideally the latest stable version) to be used at runtime rather than allowing multiple versions within an application. Using multiple library versions in one application is pretty much a worst case scenario to me -- and is generally a strong indication that someone is not keeping their software up-to-date (i.e. so that it can use the latest stable versions of the libraries it depends on). If that someone is a vendor or 3rd-party component
[The Java Posse] Netbeans 6.7 Officially Released
http://www.netbeans.org/index.html I've been using the Beta and Release Candidates for a while and it's a nice upgrade from 6.5 (the new LF for OSX is nice). Maven integration is quite swank here too. --Whaley --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Netbeans 6.7 Officially Released
Note that JavaFX is currently supported in 6.5.1, not 6.7, but is coming soon. http://www.sun.com/aboutsun/pr/2009-06/sunflash.20090629.1.xml - j On Jun 29, 2009, at 8:04 AM, Jason Whaley wrote: http://www.netbeans.org/index.html I've been using the Beta and Release Candidates for a while and it's a nice upgrade from 6.5 (the new LF for OSX is nice). Maven integration is quite swank here too. --Whaley --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] What would make you switch to a new language?
hi there, I always felt the compelling reason to switch from C/C++ to java was that there was a good set of libraries that came with java making my life easier to develop web application and break from the cgi scripts - Java had a good looking socket library that was easy to understand, nice file handling and an ok looking GUI library for little inhouse tools (compared to having to understand MFC and the windows UI programming model). Java was easier than C/C++ and it felt like developers would not have to be so smart to actually write good code - so overall it seemed to make good business sense to bet your next app on Java instead of C/C++. If one wants to replace java today, what do you think it would take? Is it going to be enough to just have a nicer, easier language? Would one need a set of API's with the language that solve some big problems we have today (and what problem is there to solve)? Is it necessary to provide a good IDE for the language right from the start? Would love to hear your comments. Ruben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: What would make you switch to a new language?
On Mon, Jun 29, 2009 at 6:13 PM, Ruben Reusser rube...@gmail.com wrote: hi there, I always felt the compelling reason to switch from C/C++ to java was that there was a good set of libraries that came with java making my life easier to develop web application and break from the cgi scripts - Java had a good looking socket library that was easy to understand, nice file handling and an ok looking GUI library for little inhouse tools (compared to having to understand MFC and the windows UI programming model). Java was easier than C/C++ and it felt like developers would not have to be so smart to actually write good code - so overall it seemed to make good business sense to bet your next app on Java instead of C/C++. If one wants to replace java today, what do you think it would take? Is it going to be enough to just have a nicer, easier language? Would one need a set of API's with the language that solve some big problems we have today (and what problem is there to solve)? Is it necessary to provide a good IDE for the language right from the start? Would love to hear your comments. My personal belief: A language that is expressive enough to write code that makes advanced functionality easy to abstract into a nice, clean syntax for business developers. So as a library consumer I can focus on getting my business rules correct and as a library producer I can create complex solutions that are easy for the consumer to consume. For me, this means: 1) Reducing line noise/boiler plate code 2) Strongly typed 3) Statically typed 4) Good tooling (IDE support et al) 5) A rich, open-source, library ecosystem Ruben -- Viktor Klang Scala Loudmouth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: What would make you switch to a new language?
A language based on: - Convension over configuration - DSL friendlyness (to a certain degree) - A hybrid type system (dynamic when you need, static when you can) - Runtime interoperability - Less is more For those reasons, I find Fan extremely interesting. /Casper On 29 Jun., 18:27, Viktor Klang viktor.kl...@gmail.com wrote: On Mon, Jun 29, 2009 at 6:13 PM, Ruben Reusser rube...@gmail.com wrote: hi there, I always felt the compelling reason to switch from C/C++ to java was that there was a good set of libraries that came with java making my life easier to develop web application and break from the cgi scripts - Java had a good looking socket library that was easy to understand, nice file handling and an ok looking GUI library for little inhouse tools (compared to having to understand MFC and the windows UI programming model). Java was easier than C/C++ and it felt like developers would not have to be so smart to actually write good code - so overall it seemed to make good business sense to bet your next app on Java instead of C/C++. If one wants to replace java today, what do you think it would take? Is it going to be enough to just have a nicer, easier language? Would one need a set of API's with the language that solve some big problems we have today (and what problem is there to solve)? Is it necessary to provide a good IDE for the language right from the start? Would love to hear your comments. My personal belief: A language that is expressive enough to write code that makes advanced functionality easy to abstract into a nice, clean syntax for business developers. So as a library consumer I can focus on getting my business rules correct and as a library producer I can create complex solutions that are easy for the consumer to consume. For me, this means: 1) Reducing line noise/boiler plate code 2) Strongly typed 3) Statically typed 4) Good tooling (IDE support et al) 5) A rich, open-source, library ecosystem Ruben -- Viktor Klang Scala Loudmouth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: What would make you switch to a new language?
On Mon, Jun 29, 2009 at 18:13, Ruben Reusserrube...@gmail.com wrote: hi there, I always felt the compelling reason to switch from C/C++ to java was that there was a good set of libraries that came with java making my life easier to develop web application and break from the cgi scripts - Java had a good looking socket library that was easy to understand, nice file handling and an ok looking GUI library for little inhouse tools (compared to having to understand MFC and the windows UI programming model). Java was easier than C/C++ and it felt like developers would not have to be so smart to actually write good code - so overall it seemed to make good business sense to bet your next app on Java instead of C/C++. If one wants to replace java today, what do you think it would take? Is it going to be enough to just have a nicer, easier language? Would one need a set of API's with the language that solve some big problems we have today (and what problem is there to solve)? Is it necessary to provide a good IDE for the language right from the start? Would love to hear your comments. (1) Provide the abstractions necessary to eliminate mindless repetition and boiler-plate code. (2) Have a [static] type system that allows me to express my intent. [But don't melt my brain.] (3) Emphasize immutability and provide data structures that make this efficient and natural. (4) Good tooling (IDE + maven) (5) Be able to interface with existing Java code. (6) Performance shouldn't suck unnecessarily. I'm currently taking my first serious dive in closure and can already see that it is strong on the following points: (1) thanks to higher order functions, closures and macros. (3) the included implementations of list/vector/map are brilliant on this count and mesh very well with the built-in concurrency abstractions. (5) Is well supported. I've dabbled with Scala before and intend to give it a more serious look when 2.8 comes out. I can see strength there in (2) and anticipate improvements in the IDE story (4). (5) Interfacing with Java has always been good. // Ben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: What would make you switch to a new language?
Is your problem with configuration rooted in the EJB2.0 madness? One of my biggest problems with Java is the actual deployment cycle to a web server. I always feel the business app lifecycle is not the supported well at the moment - a small change on the server (some text, rearrange a form, etc) seems to take to much work if the configuration is driven through annotations, etc. Or am I just missing the point? Ruben On Mon, Jun 29, 2009 at 10:09 AM, Casper Bang casper.b...@gmail.com wrote: A language based on: - Convension over configuration - DSL friendlyness (to a certain degree) - A hybrid type system (dynamic when you need, static when you can) - Runtime interoperability - Less is more For those reasons, I find Fan extremely interesting. /Casper On 29 Jun., 18:27, Viktor Klang viktor.kl...@gmail.com wrote: On Mon, Jun 29, 2009 at 6:13 PM, Ruben Reusser rube...@gmail.com wrote: hi there, I always felt the compelling reason to switch from C/C++ to java was that there was a good set of libraries that came with java making my life easier to develop web application and break from the cgi scripts - Java had a good looking socket library that was easy to understand, nice file handling and an ok looking GUI library for little inhouse tools (compared to having to understand MFC and the windows UI programming model). Java was easier than C/C++ and it felt like developers would not have to be so smart to actually write good code - so overall it seemed to make good business sense to bet your next app on Java instead of C/C++. If one wants to replace java today, what do you think it would take? Is it going to be enough to just have a nicer, easier language? Would one need a set of API's with the language that solve some big problems we have today (and what problem is there to solve)? Is it necessary to provide a good IDE for the language right from the start? Would love to hear your comments. My personal belief: A language that is expressive enough to write code that makes advanced functionality easy to abstract into a nice, clean syntax for business developers. So as a library consumer I can focus on getting my business rules correct and as a library producer I can create complex solutions that are easy for the consumer to consume. For me, this means: 1) Reducing line noise/boiler plate code 2) Strongly typed 3) Statically typed 4) Good tooling (IDE support et al) 5) A rich, open-source, library ecosystem Ruben -- Viktor Klang Scala Loudmouth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: What would make you switch to a new language?
Well my problem with configuration as found on the Java stack is fairly generic and relates both to the lack of expressiveness as well as the tendency to solve the same problem in many different ways yet no real de-facto standard (hence the less is more). During development an obscene amount of time is often spent with research, configuration and deployment rather than actually programming the solution. Annotations make things easier by getting rid of XML and tying code and configuration stronger together, but it's sometimes hard to see the gain when strings become fragile multi-lined configuration scripts. A good example of that would be ORM solutions and query capabilities between Java and Ruby(Gorm)/C#(LINQ). But it's a general thing as I said, notice for instance the problems of moving a project between IDE's because we haven't had a project standard/conversion. Maven is on the rise of course and it's the best we have, but it's also an entirely different can of configuration worms. /Casper On 29 Jun., 19:48, Ruben Reusser rube...@gmail.com wrote: Is your problem with configuration rooted in the EJB2.0 madness? One of my biggest problems with Java is the actual deployment cycle to a web server. I always feel the business app lifecycle is not the supported well at the moment - a small change on the server (some text, rearrange a form, etc) seems to take to much work if the configuration is driven through annotations, etc. Or am I just missing the point? Ruben On Mon, Jun 29, 2009 at 10:09 AM, Casper Bang casper.b...@gmail.com wrote: A language based on: - Convension over configuration - DSL friendlyness (to a certain degree) - A hybrid type system (dynamic when you need, static when you can) - Runtime interoperability - Less is more For those reasons, I find Fan extremely interesting. /Casper On 29 Jun., 18:27, Viktor Klang viktor.kl...@gmail.com wrote: On Mon, Jun 29, 2009 at 6:13 PM, Ruben Reusser rube...@gmail.com wrote: hi there, I always felt the compelling reason to switch from C/C++ to java was that there was a good set of libraries that came with java making my life easier to develop web application and break from the cgi scripts - Java had a good looking socket library that was easy to understand, nice file handling and an ok looking GUI library for little inhouse tools (compared to having to understand MFC and the windows UI programming model). Java was easier than C/C++ and it felt like developers would not have to be so smart to actually write good code - so overall it seemed to make good business sense to bet your next app on Java instead of C/C++. If one wants to replace java today, what do you think it would take? Is it going to be enough to just have a nicer, easier language? Would one need a set of API's with the language that solve some big problems we have today (and what problem is there to solve)? Is it necessary to provide a good IDE for the language right from the start? Would love to hear your comments. My personal belief: A language that is expressive enough to write code that makes advanced functionality easy to abstract into a nice, clean syntax for business developers. So as a library consumer I can focus on getting my business rules correct and as a library producer I can create complex solutions that are easy for the consumer to consume. For me, this means: 1) Reducing line noise/boiler plate code 2) Strongly typed 3) Statically typed 4) Good tooling (IDE support et al) 5) A rich, open-source, library ecosystem Ruben -- Viktor Klang Scala Loudmouth --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
I don't know if the jar duplication problem is that compelling overall. Even
several megabytes of duplicated jar's seems like a drop in the bucket these
days. Certainly it would take a lot for any serious product vendor to be
willing to relinquish control over the libraries they depend on and risk their
dependencies not getting installed properly on the client. For years, OO.o was
shipping with its own whole JRE just in case. I think it's only recently that
it's become smart enough to recognize when the client already has Java
installed.
And if we don't mind duplicated jar's, then having your own modularization
supporting multiple versions of the same jar is trivial. I wrote this as part
of my own plug-in architecture for an app several years ago:
160 public Module loadModule(Properties modConfig) throws
ModuleLoadException
161 {
162 String enabled = modConfig.getProperty(mod.enabled);
163 if(enabled != null false.equalsIgnoreCase(enabled))
164 {
165 return null;
166 }
167 URL[] cpURLs = this.getCPURLs(modConfig);
168 Module module = this.loadModule(new URLClassLoader(cpURLs,
this.getClass().getClassLoader()), modConfig.getProperty(mod.impl.class));
169 module.init(modConfig);
170 return module;
171 }
That's the crux of it and it allows each module/plug-in to initialize in the
context of its own class loader, which in turn allows me to stuff different
copies of the jar's possibly containing different versions of the same class
into different modules. No problem.
Where duplicate jars count seems to be the two opposite ends of deployment
spectrum -- mobile applications and app servers. In the case of mobile
deployments, right now we have two options: Java ME, which is as good as dead
in terms of forward momentum, and Android, which solves the modularity problem
at the core of its service-oriented architecture. And as far as app servers, I
suspect it's not a big deal for admins to keep control of shared apps and
employ whatever modularization they deem necessary -- if JVM comes with it,
they won't see a huge win over using an external modularization framework.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
From: mcculls mccu...@gmail.com
To: The Java Posse javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:21:16 AM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 12:27 pm, Augusto augusto.sellh...@gmail.com wrote:
No I mean that exactly.
I don't know, I mean the point of modularizing something for me is I
may want to use your module but I don't care about its internals. Or
at most, I don't want the internals of your module to affect me.
[disclaimer: I contribute to OSGi projects and I'm co-authoring a book
on OSGi]
exactly, that's why libraries often use tools to embed/repackage
dependencies:
http://maven.apache.org/plugins/maven-shade-plugin/
http://code.google.com/p/jarjar/
for example Guice has CGLIB and Google-Collections as internal
dependencies,
but I wouldn't want to be forced to use the same version of these
libraries when
using Guice - similarly the Guice team probably doesn't want to be
bothered with
problems caused by someone putting a different version of CGLIB before
Guice
on the classpath (the JVM will pick the first matching class when
scanning the
classpath, so ordering makes a big difference when there's overlapping
content)
so Guice repackages CGLIB and Google-Collections inside the jar -
unfortunately
this means anyone who already has those jars gets duplicate content
(~400k?)
now imagine if everyone does the same - you could end up with ten
copies of the
Google-Collection classes, embedded inside various libraries - you can
already
see this happening in applications today, and it's caused by a lack of
modularity
if there was a standard modularity system that supported multiple
versions then
the Guice team could distribute just their classes (plus the necessary
metadata)
safe in the knowledge that regardless of what jars were on the
'module' path, the
right version would be wired to Guice
that's one of the reasons why I find module systems compelling - now I
can totally
understand why you might need a special framework to modularize the
JVM, just
like the JVM has the Unsafe class for internal use - but I'm a
little bit wary about
using the same solution for applications, exactly because it might be
optimized
for the JVM (for example the no multiple versions requirement)
still hoping that JSR 294 will help bring both sides together in some
way... oh well,
time will tell - I'd hate for people to be put off the general idea of
modularity (and to
some extent programming to interfaces) as imho it does lead to better
apps
--
Cheers, Stuart
PS. many
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 2009, at 11:25 AM, Alexey Zinger wrote:
I don't know if the jar duplication problem is that compelling
overall. Even several megabytes of duplicated jar's seems like a
drop in the bucket these days.
It may be trivial for server side apps where an admin downloads and
preps the server and the app is only started once ever few weeks., but
it's a huge problem for the client side. Every extra jar adds to your
download and to your startup time. Modularity lets us to things like
only download a jar when it's actually needed, and only load up into
memory the classes that are actually used. Ex: webstart loads the xml
libs which load up java.io which load up the entire security
framework. For a simple app this is way more classes than need to be
loaded and can triple the startup time. Modularity will solve this
problem, resulting in apps that both install and start up many times
faster.
- Josh
Certainly it would take a lot for any serious product vendor to be
willing to relinquish control over the libraries they depend on and
risk their dependencies not getting installed properly on the
client. For years, OO.o was shipping with its own whole JRE just in
case. I think it's only recently that it's become smart enough to
recognize when the client already has Java installed.
And if we don't mind duplicated jar's, then having your own
modularization supporting multiple versions of the same jar is
trivial. I wrote this as part of my own plug-in architecture for an
app several years ago:
160 public Module loadModule(Properties modConfig) throws
ModuleLoadException
161 {
162 String enabled = modConfig.getProperty(mod.enabled);
163 if(enabled != null false.equalsIgnoreCase(enabled))
164 {
165 return null;
166 }
167 URL[] cpURLs = this.getCPURLs(modConfig);
168 Module module = this.loadModule(new
URLClassLoader(cpURLs,
this.getClass().getClassLoader()), modConfig.getProperty
(mod.impl.class));
169 module.init(modConfig);
170 return module;
171 }
That's the crux of it and it allows each module/plug-in to
initialize in the context of its own class loader, which in turn
allows me to stuff different copies of the jar's possibly containing
different versions of the same class into different modules. No
problem.
Where duplicate jars count seems to be the two opposite ends of
deployment spectrum -- mobile applications and app servers. In the
case of mobile deployments, right now we have two options: Java ME,
which is as good as dead in terms of forward momentum, and Android,
which solves the modularity problem at the core of its service-
oriented architecture. And as far as app servers, I suspect it's
not a big deal for admins to keep control of shared apps and employ
whatever modularization they deem necessary -- if JVM comes with it,
they won't see a huge win over using an external modularization
framework.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
From: mcculls mccu...@gmail.com
To: The Java Posse javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:21:16 AM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 12:27 pm, Augusto augusto.sellh...@gmail.com wrote:
No I mean that exactly.
I don't know, I mean the point of modularizing something for me is I
may want to use your module but I don't care about its internals. Or
at most, I don't want the internals of your module to affect me.
[disclaimer: I contribute to OSGi projects and I'm co-authoring a book
on OSGi]
exactly, that's why libraries often use tools to embed/repackage
dependencies:
http://maven.apache.org/plugins/maven-shade-plugin/
http://code.google.com/p/jarjar/
for example Guice has CGLIB and Google-Collections as internal
dependencies,
but I wouldn't want to be forced to use the same version of these
libraries when
using Guice - similarly the Guice team probably doesn't want to be
bothered with
problems caused by someone putting a different version of CGLIB before
Guice
on the classpath (the JVM will pick the first matching class when
scanning the
classpath, so ordering makes a big difference when there's overlapping
content)
so Guice repackages CGLIB and Google-Collections inside the jar -
unfortunately
this means anyone who already has those jars gets duplicate content
(~400k?)
now imagine if everyone does the same - you could end up with ten
copies of the
Google-Collection classes, embedded inside various libraries - you can
already
see this happening in applications today, and it's caused by a lack of
modularity
if there was a
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
2009/6/30 Alexey Zinger inline_f...@yahoo.com
I don't know if the jar duplication problem is that compelling overall.
Even several megabytes of duplicated jar's seems like a drop in the bucket
these days.
of course the gotcha with Google-Collections is that it includes its own
background thread to clear references,
so having several copies of that lib means several duplicate threads - but I
agree not everyone will mind that
I also like the way I can check my deployment using module metadata - I used
to spend far too long messing
around finding out exactly what jars I needed on the classpath, while with
the right metadata I can use tools
to do that for me (and it should be possible to do the same thing with
Jigsaw metadata too)
Certainly it would take a lot for any serious product vendor to be willing
to relinquish control over the libraries they depend on and risk their
dependencies not getting installed properly on the client. For years, OO.o
was shipping with its own whole JRE just in case. I think it's only
recently that it's become smart enough to recognize when the client already
has Java installed.
And if we don't mind duplicated jar's, then having your own modularization
supporting multiple versions of the same jar is trivial. I wrote
thishttp://bsheet.cvs.sourceforge.net/viewvc/bsheet/code/src/zinger/bsheet/module/ModuleFactory.java?revision=1.10view=markupas
part of my own plug-in architecture for an app several years ago:
160 public Module loadModule(Properties modConfig) throws
ModuleLoadException
161 {
162 String enabled = modConfig.getProperty(mod.enabled);
163 if(enabled != null false.equalsIgnoreCase(enabled))
164 {
165 return null;
166 }
167 URL[] cpURLs = this.getCPURLs(modConfig);
168 Module module = this.loadModule(new
URLClassLoader(cpURLs, this.getClass().getClassLoader()),
modConfig.getProperty(mod.impl.class));
169 module.init(modConfig);
170 return module;
171 }
That's the crux of it and it allows each module/plug-in to initialize in
the context of its own class loader, which in turn allows me to stuff
different copies of the jar's possibly containing different versions of the
same class into different modules. No problem.
Where duplicate jars count seems to be the two opposite ends of deployment
spectrum -- mobile applications and app servers. In the case of mobile
deployments, right now we have two options: Java ME, which is as good as
dead in terms of forward momentum, and Android, which solves the modularity
problem at the core of its service-oriented architecture. And as far as app
servers, I suspect it's not a big deal for admins to keep control of shared
apps and employ whatever modularization they deem necessary -- if JVM comes
with it, they won't see a huge win over using an external modularization
framework.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
--
*From:* mcculls mccu...@gmail.com
*To:* The Java Posse javaposse@googlegroups.com
*Sent:* Monday, June 29, 2009 3:21:16 AM
*Subject:* [The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 12:27 pm, Augusto augusto.sellh...@gmail.com wrote:
No I mean that exactly.
I don't know, I mean the point of modularizing something for me is I
may want to use your module but I don't care about its internals. Or
at most, I don't want the internals of your module to affect me.
[disclaimer: I contribute to OSGi projects and I'm co-authoring a book
on OSGi]
exactly, that's why libraries often use tools to embed/repackage
dependencies:
http://maven.apache.org/plugins/maven-shade-plugin/
http://code.google.com/p/jarjar/
for example Guice has CGLIB and Google-Collections as internal
dependencies,
but I wouldn't want to be forced to use the same version of these
libraries when
using Guice - similarly the Guice team probably doesn't want to be
bothered with
problems caused by someone putting a different version of CGLIB before
Guice
on the classpath (the JVM will pick the first matching class when
scanning the
classpath, so ordering makes a big difference when there's overlapping
content)
so Guice repackages CGLIB and Google-Collections inside the jar -
unfortunately
this means anyone who already has those jars gets duplicate content
(~400k?)
now imagine if everyone does the same - you could end up with ten
copies of the
Google-Collection classes, embedded inside various libraries - you can
already
see this happening in applications today, and it's caused by a lack of
modularity
if there was a standard modularity system that supported multiple
versions then
the Guice team could
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
modularity is part of that refactoring.
we define modules for each major component of the JRE. then we start
moving code around and cutting ties to fit this new spec. the compiler
can then enforce the modularity. of course, this takes time and not
everything will be done in the first rev of OpenJDK 7, but it's a good
start. And the good news is that the JRE will continue to get faster
and slimmer over time.
- J
On Jun 29, 2009, at 12:18 PM, Alexey Zinger wrote:
Wouldn't modularization of libraries involving XML, I/O, and
security necessitate the kind of refactoring that would result in
the same speedup in the current JVM? In theory, class loaders only
load what's necessary already, no?
Alexey
From: Joshua Marinacci jos...@gmail.com
To: javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:09:30 PM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 2009, at 11:25 AM, Alexey Zinger wrote:
I don't know if the jar duplication problem is that compelling
overall. Even several megabytes of duplicated jar's seems like a
drop in the bucket these days.
It may be trivial for server side apps where an admin downloads and
preps the server and the app is only started once ever few weeks.,
but it's a huge problem for the client side. Every extra jar adds to
your download and to your startup time. Modularity lets us to things
like only download a jar when it's actually needed, and only load up
into memory the classes that are actually used. Ex: webstart loads
the xml libs which load up java.io which load up the entire security
framework. For a simple app this is way more classes than need to
be loaded and can triple the startup time. Modularity will solve
this problem, resulting in apps that both install and start up many
times faster.
- Josh
Certainly it would take a lot for any serious product vendor to
be willing to relinquish control over the libraries they depend on
and risk their dependencies not getting installed properly on the
client. For years, OO.o was shipping with its own whole JRE just
in case. I think it's only recently that it's become smart enough
to recognize when the client already has Java installed.
And if we don't mind duplicated jar's, then having your own
modularization supporting multiple versions of the same jar is
trivial. I wrote this as part of my own plug-in architecture for
an app several years ago:
160public Module loadModule(Properties modConfig) throws
ModuleLoadException
161{
162String enabled = modConfig.getProperty(mod.enabled);
163if(enabled != null false.equalsIgnoreCase(enabled))
164{
165return null;
166}
167URL[] cpURLs = this.getCPURLs(modConfig);
168Module module = this.loadModule(new
URLClassLoader(cpURLs,
this.getClass().getClassLoader()), modConfig.getProperty
(mod.impl.class));
169module.init(modConfig);
170return module;
171}
That's the crux of it and it allows each module/plug-in to
initialize in the context of its own class loader, which in turn
allows me to stuff different copies of the jar's possibly
containing different versions of the same class into different
modules. No problem.
Where duplicate jars count seems to be the two opposite ends of
deployment spectrum -- mobile applications and app servers. In the
case of mobile deployments, right now we have two options: Java ME,
which is as good as dead in terms of forward momentum, and Android,
which solves the modularity problem at the core of its service-
oriented architecture. And as far as app servers, I suspect it's
not a big deal for admins to keep control of shared apps and employ
whatever modularization they deem necessary -- if JVM comes with
it, they won't see a huge win over using an external modularization
framework.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
From: mcculls mccu...@gmail.com
To: The Java Posse javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:21:16 AM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 12:27 pm, Augusto augusto.sellh...@gmail.com wrote:
No I mean that exactly.
I don't know, I mean the point of modularizing something for me
is I
may want to use your module but I don't care about its internals.
Or
at most, I don't want the internals of your module to affect me.
[disclaimer: I contribute to OSGi projects and I'm co-authoring a
book
on OSGi]
exactly, that's why libraries often use tools to embed/repackage
dependencies:
http://maven.apache.org/plugins/maven-shade-plugin/
http://code.google.com/p/jarjar/
[The Java Posse] Re: What would make you switch to a new language?
On Mon, Jun 29, 2009 at 11:46 AM, Casper Bang casper.b...@gmail.com wrote: Well my problem with configuration as found on the Java stack is fairly generic and relates both to the lack of expressiveness as well as the tendency to solve the same problem in many different ways yet no real de-facto standard (hence the less is more). During development an obscene amount of time is often spent with research, configuration and deployment rather than actually programming the solution. I am still puzzled about the fact that the configuration is bound into the classes with annotation and needs a redeployment for any minor change - while ok during development, it's a nightmare during production and if the business wants to change a little thing in the application. Annotations make things easier by getting rid of XML and tying code and configuration stronger together, but it's sometimes hard to see the gain when strings become fragile multi-lined configuration scripts. A good example of that would be ORM solutions and query capabilities between Java and Ruby(Gorm)/C#(LINQ). But it's a general thing as I said, notice for instance the problems of moving a project between IDE's because we haven't had a project standard/conversion. Maven is on the rise of course and it's the best we have, but it's also an entirely different can of configuration worms. /Casper --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: What would make you switch to a new language?
Ruben Reusser wrote: On Mon, Jun 29, 2009 at 11:46 AM, Casper Bang casper.b...@gmail.com mailto:casper.b...@gmail.com wrote: Well my problem with configuration as found on the Java stack is fairly generic and relates both to the lack of expressiveness as well as the tendency to solve the same problem in many different ways yet no real de-facto standard (hence the less is more). During development an obscene amount of time is often spent with research, configuration and deployment rather than actually programming the solution. I am still puzzled about the fact that the configuration is bound into the classes with annotation and needs a redeployment for any minor change - while ok during development, it's a nightmare during production and if the business wants to change a little thing in the application. I would think that only the /default/ configuration should be bound in with annotations and that configuration files should then be used to override this as needed. That's the best of both worlds. -- Jess Holle --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
Right, but my question is, once the necessary refactoring is done, will the JVM
benefit from the same startup time boost just by relying on current class
loader implementations as it would by loading those pieces via a module
framework?
Alexey
From: Joshua Marinacci jos...@gmail.com
To: javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:23:01 PM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
modularity is part of that refactoring.
we define modules for each major component of the JRE. then we start moving
code around and cutting ties to fit this new spec. the compiler can then
enforce the modularity. of course, this takes time and not everything will be
done in the first rev of OpenJDK 7, but it's a good start. And the good news is
that the JRE will continue to get faster and slimmer over time.
- J
On Jun 29, 2009, at 12:18 PM, Alexey Zinger wrote:
Wouldn't modularization of libraries involving XML, I/O, and security
necessitate the kind of refactoring that would result in the same speedup in
the current JVM? In theory, class loaders only load what's necessary already,
no?
Alexey
From: Joshua Marinacci jos...@gmail.com
To: javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:09:30 PM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 2009, at 11:25 AM, Alexey Zinger wrote:
I don't know if the jar duplication problem is that compelling overall. Even
several megabytes of duplicated jar's seems like a drop in the bucket these
days.
It may be trivial for server side apps where an admin downloads and preps the
server and the app is only started once ever few weeks., but it's a huge
problem for the client side. Every extra jar adds to your download and to your
startup time. Modularity lets us to things like only download a jar when it's
actually needed, and only load up into memory the classes that are actually
used. Ex: webstart loads the xml libs which load up java.io which load up the
entire security framework. For a simple app this is way more classes than
need to be loaded and can triple the startup time. Modularity will solve this
problem, resulting in apps that both install and start up many times faster.
- Josh
Certainly it would take a lot for any serious product vendor to be willing
to relinquish control over the libraries they depend on and risk their
dependencies not getting installed properly on the client. For years, OO.o
was shipping with its own whole JRE just in case. I think it's only recently
that it's become smart enough to recognize when the client already has Java
installed.
And if we don't mind duplicated jar's, then having your own modularization
supporting multiple versions of the same jar is trivial. I wrote this as
part of my own plug-in architecture for an app several years ago:
160 public Module loadModule(Properties modConfig) throws
ModuleLoadException
161 {
162 String enabled = modConfig.getProperty(mod.enabled);
163 if(enabled != null false.equalsIgnoreCase(enabled))
164 {
165 return null;
166 }
167 URL[] cpURLs = this.getCPURLs(modConfig);
168 Module module = this.loadModule(new
URLClassLoader(cpURLs, this.getClass().getClassLoader()),
modConfig.getProperty(mod.impl.class));
169 module.init(modConfig);
170 return module;
171 }
That's the crux of it and it allows each module/plug-in to initialize in the
context of its own class loader, which in turn allows me to stuff different
copies of the jar's possibly containing different versions of the same class
into different modules. No problem.
Where duplicate jars count seems to be the two opposite ends of deployment
spectrum -- mobile applications and app servers. In the case of mobile
deployments, right now we have two options: Java ME, which is as good as dead
in terms of forward momentum, and Android, which solves the modularity
problem at the core of its service-oriented architecture. And as far as app
servers, I suspect it's not a big deal for admins to keep control of shared
apps and employ whatever modularization they deem necessary -- if JVM comes
with it, they won't see a huge win over using an external modularization
framework.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
From: mcculls mccu...@gmail.com
To: The Java Posse javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:21:16 AM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 12:27 pm, Augusto augusto.sellh...@gmail.com wrote:
No I mean that exactly.
I don't know, I mean the point of
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
I'm not sure. My impression from the jigsaw interview is that the
modules are primarily a compile time thing. At runtime all of the
stuff in the bootclasspath will still get loaded by a single
classloader, but potentially faster and skipping the unnecessary
classes.
- J
On Jun 29, 2009, at 12:53 PM, Alexey Zinger wrote:
Right, but my question is, once the necessary refactoring is done,
will the JVM benefit from the same startup time boost just by
relying on current class loader implementations as it would by
loading those pieces via a module framework?
Alexey
From: Joshua Marinacci jos...@gmail.com
To: javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:23:01 PM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
modularity is part of that refactoring.
we define modules for each major component of the JRE. then we start
moving code around and cutting ties to fit this new spec. the
compiler can then enforce the modularity. of course, this takes
time and not everything will be done in the first rev of OpenJDK 7,
but it's a good start. And the good news is that the JRE will
continue to get faster and slimmer over time.
- J
On Jun 29, 2009, at 12:18 PM, Alexey Zinger wrote:
Wouldn't modularization of libraries involving XML, I/O, and
security necessitate the kind of refactoring that would result in
the same speedup in the current JVM? In theory, class loaders only
load what's necessary already, no?
Alexey
From: Joshua Marinacci jos...@gmail.com
To: javaposse@googlegroups.com
Sent: Monday, June 29, 2009 3:09:30 PM
Subject: [The Java Posse] Re: more jigsaw vs osgi vs javaposse
On Jun 29, 2009, at 11:25 AM, Alexey Zinger wrote:
I don't know if the jar duplication problem is that compelling
overall. Even several megabytes of duplicated jar's seems like a
drop in the bucket these days.
It may be trivial for server side apps where an admin downloads and
preps the server and the app is only started once ever few weeks.,
but it's a huge problem for the client side. Every extra jar adds
to your download and to your startup time. Modularity lets us to
things like only download a jar when it's actually needed, and only
load up into memory the classes that are actually used. Ex:
webstart loads the xml libs which load up java.io which load up the
entire security framework. For a simple app this is way more
classes than need to be loaded and can triple the startup time.
Modularity will solve this problem, resulting in apps that both
install and start up many times faster.
- Josh
Certainly it would take a lot for any serious product vendor to
be willing to relinquish control over the libraries they depend on
and risk their dependencies not getting installed properly on the
client. For years, OO.o was shipping with its own whole JRE just
in case. I think it's only recently that it's become smart enough
to recognize when the client already has Java installed.
And if we don't mind duplicated jar's, then having your own
modularization supporting multiple versions of the same jar is
trivial. I wrote this as part of my own plug-in architecture for
an app several years ago:
160 public Module loadModule(Properties modConfig) throws
ModuleLoadException
161 {
162 String enabled = modConfig.getProperty(mod.enabled);
163 if(enabled != null false.equalsIgnoreCase(enabled))
164 {
165 return null;
166 }
167 URL[] cpURLs = this.getCPURLs(modConfig);
168 Module module = this.loadModule(new
URLClassLoader(cpURLs,
this.getClass().getClassLoader()), modConfig.getProperty
(mod.impl.class));
169 module.init(modConfig);
170 return module;
171 }
That's the crux of it and it allows each module/plug-in to
initialize in the context of its own class loader, which in turn
allows me to stuff different copies of the jar's possibly
containing different versions of the same class into different
modules. No problem.
Where duplicate jars count seems to be the two opposite ends of
deployment spectrum -- mobile applications and app servers. In
the case of mobile deployments, right now we have two options:
Java ME, which is as good as dead in terms of forward momentum,
and Android, which solves the modularity problem at the core of
its service-oriented architecture. And as far as app servers, I
suspect it's not a big deal for admins to keep control of shared
apps and employ whatever modularization they deem necessary -- if
JVM comes with it, they won't see a huge win over using an
external modularization framework.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
[The Java Posse] Google isn't the one missing the point
Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: there once was a language called scala
Clearly I've been spending too much time writing code, because (_ + _) just looks filthy to me. - DAemon 2009/6/29 Mwanji Ezana mwa...@gmail.com On Jun 29, 8:33 am, Vince O'Sullivan vjosulli...@gmail.com wrote: I hope you write better code than poetry! I liked it. I think a trampolining koala and a recursively leaping impala are great images. Certainly, they are comforting when confronted with (_ + _) or some such. Mwanji --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
Agreed. Though discoverable data is of near infinite benefit to Google and /far/ more limited value to those trying to write an /application/ vs. those primarily focused on presenting content. Yes, that's a blurry distinction, but there are clear extremes here -- ThinkFree on the one hand vs. Wikipedia on the other. Google's not evil here, but clearly what's best for them isn't necessarily best for everyone (not even everyone but their competitors). -- Jess Holle ctwise wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: What would make you switch to a new language?
Ruben, I think one of the big things Java did was to solve the memory management issues (at least to a large extent). The next problem to solve is IMO concurrency, which is much too complicated with the current programming model. While there are solutions for that out there, I believe they deviate too much from Java in the details. Unfortunately details do matter and I believe part of Java's success was that it looked much like C++. Libraries matter and I suspect that nowadays Java would have a harder time to replace C++ since it seems they finally got some agreement on what String class to use (but maybe I'm wrong). Java covers pretty much everything, and while I personally believe the collections API is a pile of dung from a conceptual point of view, it is an existing standard with decent implementations. It won't be as easy to replace that as it was pushing something new on C++ developers who just didn't have any standard at the time (unless you were in MS land). I also would not switch my main language unless there is a full story for IDEs (including refactoring and debugging) as well as the build tooling (including support in CI systems). A tough call, but I am spoiled. That doesn't mean I personally don't touch other languages. I have toyed with Scala and I have used Grails on a prototype, but with the former I still feel like creating a bus problem and with the latter I find I code much less agile than what I do in Java. That last statement may sound weird, but since I tend to rely on static typing and refactoring tools a lot, Groovy is not my thing. It's nice to write code in, but for any renaming or repackaging it tends to be awkward. This means my decisions are bound much stronger, which means I'm less agile. Part of that is just the web-app story (no wonder these languages are more popular there), but I think Groovy adds its bit. And I also find myself reading JavaDoc again -- I haven't done that in years since I normally have the source attached and my IDE can take me there. Try using POIs weird API in Groovy and you'll miss something. Long story, shorter conclusion: what I would be looking for is a language that looks very Javaish and has strong static typing. Stronger than Java (at least explicit nullability and closures, no broken arrays, join and union types, maybe even simple constraints such as Integer[0..5]) and with IDE support that makes good use of all that information I can then express. Add some decent concurrency support into that and then we start talking about something I'd call Java's Java. Something I can see going mainstream, as opposed to all the current candidates. Peter Ruben Reusser wrote: hi there, I always felt the compelling reason to switch from C/C++ to java was that there was a good set of libraries that came with java making my life easier to develop web application and break from the cgi scripts - Java had a good looking socket library that was easy to understand, nice file handling and an ok looking GUI library for little inhouse tools (compared to having to understand MFC and the windows UI programming model). Java was easier than C/C++ and it felt like developers would not have to be so smart to actually write good code - so overall it seemed to make good business sense to bet your next app on Java instead of C/C++. If one wants to replace java today, what do you think it would take? Is it going to be enough to just have a nicer, easier language? Would one need a set of API's with the language that solve some big problems we have today (and what problem is there to solve)? Is it necessary to provide a good IDE for the language right from the start? Would love to hear your comments. Ruben --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
Then again, GWT isn't exactly addressable/discoverable. In general I like Google for embracing the web, often it seems like everyone runs away from it and invents complex and artificial layers that we then can't use from all our devices (think iPhone/Android). I suppose applets were the worst of these layers. The best was XUL in my opinion. /Casper On 30 Jun., 01:46, Jess Holle je...@ptc.com wrote: Agreed. Though discoverable data is of near infinite benefit to Google and /far/ more limited value to those trying to write an /application/ vs. those primarily focused on presenting content. Yes, that's a blurry distinction, but there are clear extremes here -- ThinkFree on the one hand vs. Wikipedia on the other. Google's not evil here, but clearly what's best for them isn't necessarily best for everyone (not even everyone but their competitors). -- Jess Holle ctwise wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
GWT is absolutely not addressable/discoverable. Google can't search your GWT site unless you add something like an atom feed and design the GWT pages to react according when somebody hits a deep (yet fake) link into your site. The same strategy will work for Flash/Silverlight/JavaFX or whatever system you use to add client-side pizazz to your site. On Jun 29, 8:17 pm, Casper Bang casper.b...@gmail.com wrote: Then again, GWT isn't exactly addressable/discoverable. In general I like Google for embracing the web, often it seems like everyone runs away from it and invents complex and artificial layers that we then can't use from all our devices (think iPhone/Android). I suppose applets were the worst of these layers. The best was XUL in my opinion. /Casper On 30 Jun., 01:46, Jess Holle je...@ptc.com wrote: Agreed. Though discoverable data is of near infinite benefit to Google and /far/ more limited value to those trying to write an /application/ vs. those primarily focused on presenting content. Yes, that's a blurry distinction, but there are clear extremes here -- ThinkFree on the one hand vs. Wikipedia on the other. Google's not evil here, but clearly what's best for them isn't necessarily best for everyone (not even everyone but their competitors). -- Jess Holle ctwise wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
If it wasn't for the pressure of something like SWT. The folks at sun might not have responded as quickly as they did to improve performance in swing, etc. a little competition is good for all of us. I don't think SWT ever did damage to the community. it provided a performant GUI library when it looked like swing was not addressing the problem. On Jun 27, 8:57 am, Chris Adamson invalidn...@gmail.com wrote: The OSGi zealots remind me of the SWT zealots... and are poised to do just as much damage to the Java community. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
I think a little history is in order. My recollection is that in both cases there was a solution generated that addressed something that Sun either was not addressing (SWT - performance, OSGI-Modularity, class path issues, etc). or was not prioritizing high enough for folks that were trying to adopt Java for commercial usage. In the case of the two module systems, I believe a major complaint that the OSGI camp had was that in the initial working group they were not invited to participate. if you want to engage someone and get their support, best way to do it is to make the solution part of their problem to solve and engage them for the concerns they may have with what appears to be a parallel effort (which appeared to them as an attempt to damage, hurt the effort they had engaged in). On Jun 27, 8:57 am, Chris Adamson invalidn...@gmail.com wrote: The OSGi zealots remind me of the SWT zealots... and are poised to do just as much damage to the Java community. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
Not sure if that is right - discoverable data is more a function of what the app does, more so then how it is built. Google index flash web sites quite heavily, and in flash you can make things dicoverable as well. Also, look at GMail, Wave etc - how are they discoverable Don't confuse web sites (all about content/nouns) with web apps (all about the actions/verbs) - latter is what is up for debate really. Even the former built in flash if you want is indexable. On Jun 30, 5:56 am, ctwise ctw...@gmail.com wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: more jigsaw vs osgi vs javaposse
I believe SWT was a great kick in Sun's pants to get them to fix Swing, etc. Now that it has done that I believe it has *no* reason to exist and is a essentially the single reason I'd never choose to use the Eclipse RCP. -- Jess Holle Lhasadad wrote: If it wasn't for the pressure of something like SWT. The folks at sun might not have responded as quickly as they did to improve performance in swing, etc. a little competition is good for all of us. I don't think SWT ever did damage to the community. it provided a performant GUI library when it looked like swing was not addressing the problem. On Jun 27, 8:57 am, Chris Adamson invalidn...@gmail.com wrote: The OSGi zealots remind me of the SWT zealots... and are poised to do just as much damage to the Java community. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~-- --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
True, there's a difference between wide-spectred content websites (typically the Internet) and applications (typically intranets). I would distinguish discoverable from addressable (think REST) in what it allows, particular in relation to a semantic web and a full fledged hypermedia system. Notice for instance, as you click on a message in GMail, how you navigate to a unique item under your inbox with the back button working as an undo. Could that be done with Silverlight, Flash and JavaFX? /Casper On 30 Jun., 03:17, Michael Neale michael.ne...@gmail.com wrote: Not sure if that is right - discoverable data is more a function of what the app does, more so then how it is built. Google index flash web sites quite heavily, and in flash you can make things dicoverable as well. Also, look at GMail, Wave etc - how are they discoverable Don't confuse web sites (all about content/nouns) with web apps (all about the actions/verbs) - latter is what is up for debate really. Even the former built in flash if you want is indexable. On Jun 30, 5:56 am, ctwise ctw...@gmail.com wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
As has been pointed out, major search indexes inspect Flash content. Surely initialization DOM manipulation via Javascript is indexed as well. GWT also encourages REST'ful style of building web apps. The days of having express everything you needed indexed in HTML alone are gone. Alexey From: Casper Bang casper.b...@gmail.com To: The Java Posse javaposse@googlegroups.com Sent: Monday, June 29, 2009 8:17:52 PM Subject: [The Java Posse] Re: Google isn't the one missing the point Then again, GWT isn't exactly addressable/discoverable. In general I like Google for embracing the web, often it seems like everyone runs away from it and invents complex and artificial layers that we then can't use from all our devices (think iPhone/Android). I suppose applets were the worst of these layers. The best was XUL in my opinion. /Casper On 30 Jun., 01:46, Jess Holle je...@ptc.com wrote: Agreed. Though discoverable data is of near infinite benefit to Google and /far/ more limited value to those trying to write an /application/ vs. those primarily focused on presenting content. Yes, that's a blurry distinction, but there are clear extremes here -- ThinkFree on the one hand vs. Wikipedia on the other. Google's not evil here, but clearly what's best for them isn't necessarily best for everyone (not even everyone but their competitors). -- Jess Holle ctwise wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
+1 This rant seemed odd, especially bringing up flex so much. Does anybody honestly believe google would consider using flex for the wave ui?! Flash support is still bad in unix. Flex has its place, especially in the business app world, but is disliked by many and the interfaces are often clumsy or even inaccessible to some. JavaFx just isn't open or mature yet, and obviously Silverlight is not an option. Google has been all about speeding up javascript and making the browser the app platform. Open standards/Chrome/javascript/html is decidedly the google client platform of choice. Adam On Jun 29, 2:56 pm, ctwise ctw...@gmail.com wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
Practically speaking, I can see the benefits of flex and flash - I have used some great apps in them, and adobe do some really cool stuff, and are very friendly to developers. But the reason flash works as well as it does compared to browsers is largely due to it being just 1 runtime vendor to target (and its still not open source) - it would be more interesting to more folks of they would completely open up the runtime - certainly would level the playing field a bit. As it stands now, adobe don't seem at all open to that, and that worries me (there is gnash of course, but then you have the issue just the same as the browsers - you get different behaviors in different runtime implementations). On Jun 30, 12:44 pm, ad adam.denn...@gmail.com wrote: +1 This rant seemed odd, especially bringing up flex so much. Does anybody honestly believe google would consider using flex for the wave ui?! Flash support is still bad in unix. Flex has its place, especially in the business app world, but is disliked by many and the interfaces are often clumsy or even inaccessible to some. JavaFx just isn't open or mature yet, and obviously Silverlight is not an option. Google has been all about speeding up javascript and making the browser the app platform. Open standards/Chrome/javascript/html is decidedly the google client platform of choice. Adam On Jun 29, 2:56 pm, ctwise ctw...@gmail.com wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
Hi Ad I brought up flash because of all of the options discussed, it is the most widely disseminated in a usable form (much higher penetration than HTML 5 considering IE 6 and 7 don't have support for it yet, nor does Firefox 3). I do agree that HTML 5 availability will grow as browsers move forward, but I also have my issues with the promise of GWT - for example, while I have been using the firefox 3.5 beta for some time as my primary browser, it has not been supported by GWT. I just went to the GWT site to look at the list of supported browsers and I can't seem to find it right now (can anyone point me to it - I like to have my facts straight). Without strong support and clear details on supported browsers, and timetables for their support, I would not want to commit a project to using GWT when it might result in people not being able to use my site. I am playing devils advocate a little. Open standards are, of course, good. I think there are some valid reasons to question the HTML 5/ browser only approach though - if only to get a discussion going. I don't believe Google will develop a flash version of wave, even though they do use flash heavily for other services (analytics, finance, youtube, etc.). However it is noteworthy that the selling point of wave seems to be look at what we can do in the browser! rather than look at what we can do!. I also fully expect to see flash or JavaFX wave clients quickly pass the browser version in terms of pizazz and functionality, although I think the browser version will rule for market share. I think we should not be to caught up in what we can do in the browser though as the be-all and end-all of development. I think a future solely consisting of web applications is a limited one indeed. Several people have addressed the question of accessibility already, but I will point out that a pure javascript application is no more inherently accessible than a flex one - I know this was a big focus of T.V. Raman when I worked at Google - how to make GWT and JavaScript behave nicely for the visually impaired and other accessibility concerns. Anyway - I believe it made for a good discussion, which was the point after all. I think the next few years are going to be interesting. Dick On Jun 29, 7:44 pm, ad adam.denn...@gmail.com wrote: +1 This rant seemed odd, especially bringing up flex so much. Does anybody honestly believe google would consider using flex for the wave ui?! Flash support is still bad in unix. Flex has its place, especially in the business app world, but is disliked by many and the interfaces are often clumsy or even inaccessible to some. JavaFx just isn't open or mature yet, and obviously Silverlight is not an option. Google has been all about speeding up javascript and making the browser the app platform. Open standards/Chrome/javascript/html is decidedly the google client platform of choice. Adam On Jun 29, 2:56 pm, ctwise ctw...@gmail.com wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
Thanks for the thoughtful reply Dick. Gotcha on playing devils advocate a bit, and you certainly spawned a lively discussion! I've never used a desktop browser google apps didn't work on, and am primarily a linux user. I assumed GWT targeted anything worth targeting. I seem to remember hearing GWT generating something like 10 versions of javascript includes for different user agents (as opposed to frameworks like jquery or mootools that handle variations in a single source). You make a good point about google using flash elsewhere, although the biggest case is an acquired business. I doubt we will see new development in flash by google as they continue to push HTML5 hard. Perhaps pure flex apps are not inherently less accessible/usable than javascript/html, but it sure feels that way, don't ya think? I mean, how many times have you wanted ctrl+f to search for a text string, or been aggravated that your clipboard didn't work, or back buttons didn't behave as expected? I use flex at work and know it doesn't have to be this way. It is neat stuff, and I even kinda like actionscript, but live in the nix community where flash is hated (then again, java often is too, sigh). I tend to agree that before long the browser will not be the dominant platform for web apps, and actually predict javafx will rule the world. Note that this is coming from someone who hasn't had to time to play with javafx, but enjoys making uneducated predictions smile cheers, Adam On Jun 29, 10:50 pm, Dick Wall dickw...@gmail.com wrote: Hi Ad I brought up flash because of all of the options discussed, it is the most widely disseminated in a usable form (much higher penetration than HTML 5 considering IE 6 and 7 don't have support for it yet, nor does Firefox 3). I do agree that HTML 5 availability will grow as browsers move forward, but I also have my issues with the promise of GWT - for example, while I have been using the firefox 3.5 beta for some time as my primary browser, it has not been supported by GWT. I just went to the GWT site to look at the list of supported browsers and I can't seem to find it right now (can anyone point me to it - I like to have my facts straight). Without strong support and clear details on supported browsers, and timetables for their support, I would not want to commit a project to using GWT when it might result in people not being able to use my site. I am playing devils advocate a little. Open standards are, of course, good. I think there are some valid reasons to question the HTML 5/ browser only approach though - if only to get a discussion going. I don't believe Google will develop a flash version of wave, even though they do use flash heavily for other services (analytics, finance, youtube, etc.). However it is noteworthy that the selling point of wave seems to be look at what we can do in the browser! rather than look at what we can do!. I also fully expect to see flash or JavaFX wave clients quickly pass the browser version in terms of pizazz and functionality, although I think the browser version will rule for market share. I think we should not be to caught up in what we can do in the browser though as the be-all and end-all of development. I think a future solely consisting of web applications is a limited one indeed. Several people have addressed the question of accessibility already, but I will point out that a pure javascript application is no more inherently accessible than a flex one - I know this was a big focus of T.V. Raman when I worked at Google - how to make GWT and JavaScript behave nicely for the visually impaired and other accessibility concerns. Anyway - I believe it made for a good discussion, which was the point after all. I think the next few years are going to be interesting. Dick On Jun 29, 7:44 pm, ad adam.denn...@gmail.com wrote: +1 This rant seemed odd, especially bringing up flex so much. Does anybody honestly believe google would consider using flex for the wave ui?! Flash support is still bad in unix. Flex has its place, especially in the business app world, but is disliked by many and the interfaces are often clumsy or even inaccessible to some. JavaFx just isn't open or mature yet, and obviously Silverlight is not an option. Google has been all about speeding up javascript and making the browser the app platform. Open standards/Chrome/javascript/html is decidedly the google client platform of choice. Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
GWT works fine with Firefox3.5, just tried it. I think early betas of FF tend to get pushed hard by complex ajax apps, which GWT certainly generates. GWT tends to compile different versions for the families of browsers it supports. On Jun 30, 1:50 pm, Dick Wall dickw...@gmail.com wrote: Hi Ad I brought up flash because of all of the options discussed, it is the most widely disseminated in a usable form (much higher penetration than HTML 5 considering IE 6 and 7 don't have support for it yet, nor does Firefox 3). I do agree that HTML 5 availability will grow as browsers move forward, but I also have my issues with the promise of GWT - for example, while I have been using the firefox 3.5 beta for some time as my primary browser, it has not been supported by GWT. I just went to the GWT site to look at the list of supported browsers and I can't seem to find it right now (can anyone point me to it - I like to have my facts straight). Without strong support and clear details on supported browsers, and timetables for their support, I would not want to commit a project to using GWT when it might result in people not being able to use my site. I am playing devils advocate a little. Open standards are, of course, good. I think there are some valid reasons to question the HTML 5/ browser only approach though - if only to get a discussion going. I don't believe Google will develop a flash version of wave, even though they do use flash heavily for other services (analytics, finance, youtube, etc.). However it is noteworthy that the selling point of wave seems to be look at what we can do in the browser! rather than look at what we can do!. I also fully expect to see flash or JavaFX wave clients quickly pass the browser version in terms of pizazz and functionality, although I think the browser version will rule for market share. I think we should not be to caught up in what we can do in the browser though as the be-all and end-all of development. I think a future solely consisting of web applications is a limited one indeed. Several people have addressed the question of accessibility already, but I will point out that a pure javascript application is no more inherently accessible than a flex one - I know this was a big focus of T.V. Raman when I worked at Google - how to make GWT and JavaScript behave nicely for the visually impaired and other accessibility concerns. Anyway - I believe it made for a good discussion, which was the point after all. I think the next few years are going to be interesting. Dick On Jun 29, 7:44 pm, ad adam.denn...@gmail.com wrote: +1 This rant seemed odd, especially bringing up flex so much. Does anybody honestly believe google would consider using flex for the wave ui?! Flash support is still bad in unix. Flex has its place, especially in the business app world, but is disliked by many and the interfaces are often clumsy or even inaccessible to some. JavaFx just isn't open or mature yet, and obviously Silverlight is not an option. Google has been all about speeding up javascript and making the browser the app platform. Open standards/Chrome/javascript/html is decidedly the google client platform of choice. Adam On Jun 29, 2:56 pm, ctwise ctw...@gmail.com wrote: Google wants very much for everything to move to HTML. They don't want Flash. They don't want Silverlight. They don't want JavaFX. All of those technologies move us away from discoverable data and all of the benefits of simple HTML. HTML5 and Chrome are an attempt to make Flash and plug-ins pointless. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
hmm, all I know is from the wave demo watching google i/o videos, but am almost sure I heard some piece of it at least required HTML5. I think they only used safari and firefox for this reason. Adam On Jun 29, 11:51 pm, Michael Neale michael.ne...@gmail.com wrote: note that Wave doesn't require HTML5 at all, not sure where that came from? On Jun 30, 1:50 pm, Dick Wall dickw...@gmail.com wrote: Hi Ad I brought up flash because of all of the options discussed, it is the most widely disseminated in a usable form (much higher penetration than HTML 5 considering IE 6 and 7 don't have support for it yet, nor does Firefox 3). I do agree that HTML 5 availability will grow as browsers move forward, but I also have my issues with the promise of GWT - for example, while I have been using the firefox 3.5 beta for some time as my primary browser, it has not been supported by GWT. I just went to the GWT site to look at the list of supported browsers and I can't seem to find it right now (can anyone point me to it - I like to have my facts straight). Without strong support and clear details on supported browsers, and timetables for their support, I would not want to commit a project to using GWT when it might result in people not being able to use my site. I am playing devils advocate a little. Open standards are, of course, good. I think there are some valid reasons to question the HTML 5/ browser only approach though - if only to get a discussion going. I don't believe Google will develop a flash version of wave, even though they do use flash heavily for other services (analytics, finance, youtube, etc.). However it is noteworthy that the selling point of wave seems to be look at what we can do in the browser! rather than look at what we can do!. I also fully expect to see flash or JavaFX wave clients quickly pass the browser version in terms of pizazz and functionality, although I think the browser version will rule for market share. I think we should not be to caught up in what we can do in the browser though as the be-all and end-all of development. I think a future solely consisting of web applications is a limited one indeed. Several people have addressed the question of accessibility already, but I will point out that a pure javascript application is no more inherently accessible than a flex one - I know this was a big focus of T.V. Raman when I worked at Google - how to make GWT and JavaScript behave nicely for the visually impaired and other accessibility concerns. Anyway - I believe it made for a good discussion, which was the point after all. I think the next few years are going to be interesting. Dick On Jun 29, 7:44 pm, ad adam.denn...@gmail.com wrote: +1 This rant seemed odd, especially bringing up flex so much. Does anybody honestly believe google would consider using flex for the wave ui?! Flash support is still bad in unix. Flex has its place, especially in the business app world, but is disliked by many and the interfaces are often clumsy or even inaccessible to some. JavaFx just isn't open or mature yet, and obviously Silverlight is not an option. Google has been all about speeding up javascript and making the browser the app platform. Open standards/Chrome/javascript/html is decidedly the google client platform of choice. Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
Are you thinking of the drag and drop which is currently NOT supported by HTML5? http://www.youtube.com/watch?v=v_UyVmITiYQ#t=16m16s It does not matter either way, because by the time wave is done, all vendors will have an HTML5-ready version. I'm pretty sure that 95% of the people will upgrade when they get a whiff -- or spume if you will -- of wave (assuming it will fulfill all my wild fantasies.. ;). With kind regards Ben On Jun 30, 7:00 am, ad adam.denn...@gmail.com wrote: hmm, all I know is from the wave demo watching google i/o videos, but am almost sure I heard some piece of it at least required HTML5. I think they only used safari and firefox for this reason. Adam On Jun 29, 11:51 pm, Michael Neale michael.ne...@gmail.com wrote: note that Wave doesn't require HTML5 at all, not sure where that came from? On Jun 30, 1:50 pm, Dick Wall dickw...@gmail.com wrote: Hi Ad I brought up flash because of all of the options discussed, it is the most widely disseminated in a usable form (much higher penetration than HTML 5 considering IE 6 and 7 don't have support for it yet, nor does Firefox 3). I do agree that HTML 5 availability will grow as browsers move forward, but I also have my issues with the promise of GWT - for example, while I have been using the firefox 3.5 beta for some time as my primary browser, it has not been supported by GWT. I just went to the GWT site to look at the list of supported browsers and I can't seem to find it right now (can anyone point me to it - I like to have my facts straight). Without strong support and clear details on supported browsers, and timetables for their support, I would not want to commit a project to using GWT when it might result in people not being able to use my site. I am playing devils advocate a little. Open standards are, of course, good. I think there are some valid reasons to question the HTML 5/ browser only approach though - if only to get a discussion going. I don't believe Google will develop a flash version of wave, even though they do use flash heavily for other services (analytics, finance, youtube, etc.). However it is noteworthy that the selling point of wave seems to be look at what we can do in the browser! rather than look at what we can do!. I also fully expect to see flash or JavaFX wave clients quickly pass the browser version in terms of pizazz and functionality, although I think the browser version will rule for market share. I think we should not be to caught up in what we can do in the browser though as the be-all and end-all of development. I think a future solely consisting of web applications is a limited one indeed. Several people have addressed the question of accessibility already, but I will point out that a pure javascript application is no more inherently accessible than a flex one - I know this was a big focus of T.V. Raman when I worked at Google - how to make GWT and JavaScript behave nicely for the visually impaired and other accessibility concerns. Anyway - I believe it made for a good discussion, which was the point after all. I think the next few years are going to be interesting. Dick On Jun 29, 7:44 pm, ad adam.denn...@gmail.com wrote: +1 This rant seemed odd, especially bringing up flex so much. Does anybody honestly believe google would consider using flex for the wave ui?! Flash support is still bad in unix. Flex has its place, especially in the business app world, but is disliked by many and the interfaces are often clumsy or even inaccessible to some. JavaFx just isn't open or mature yet, and obviously Silverlight is not an option. Google has been all about speeding up javascript and making the browser the app platform. Open standards/Chrome/javascript/html is decidedly the google client platform of choice. Adam --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
[The Java Posse] Re: Google isn't the one missing the point
Ben, Nice recall. Yup, that is exactly what I was completely incorrectly thinking of. Adam On Jun 30, 12:26 am, Ben Schulz ya...@gmx.net wrote: Are you thinking of the drag and drop which is currently NOT supported by HTML5? http://www.youtube.com/watch?v=v_UyVmITiYQ#t=16m16s It does not matter either way, because by the time wave is done, all vendors will have an HTML5-ready version. I'm pretty sure that 95% of the people will upgrade when they get a whiff -- or spume if you will -- of wave (assuming it will fulfill all my wild fantasies.. ;). With kind regards Ben On Jun 30, 7:00 am, ad adam.denn...@gmail.com wrote: hmm, all I know is from the wave demo watching google i/o videos, but am almost sure I heard some piece of it at least required HTML5. I think they only used safari and firefox for this reason. Adam On Jun 29, 11:51 pm, Michael Neale michael.ne...@gmail.com wrote: note that Wave doesn't require HTML5 at all, not sure where that came from? On Jun 30, 1:50 pm, Dick Wall dickw...@gmail.com wrote: --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups The Java Posse group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~--~~~~--~~--~--~---
