• Save
Polyglot OSGi
Upcoming SlideShare
Loading in...5
×
 

Polyglot OSGi

on

  • 2,713 views

 

Statistics

Views

Total Views
2,713
Views on SlideShare
2,441
Embed Views
272

Actions

Likes
6
Downloads
0
Comments
0

5 Embeds 272

http://freethinker.addinq.uy 254
http://www.slideshare.net 7
http://feedly.com 5
http://www.mattstine.com 3
http://bestaroundtheweb.com 3

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Today I&#x2019;d like to talk to you briefly about why within the next decade you&#x2019;ll no longer refer to yourself as a Java developer, at least not in terms of the language that you use on a day to day basis. And at the end of my lighting talk I&#x2019;ll have a prize for the first person that can identify both the artist and title of the sketch that I have here in my slides. <br />
  • <br />
  • The word polyglot is used in various contexts to indicate that many languages are in use. It can be used as an adjective to describe a work containing several languages, such as a polyglot Bible. We can also use it to describe a region comprising various linguistic groups - a notable example is India which recognizes 22 official languages and can number over a thousand individual &#x201C;mother tongues.&#x201D; We can also describe a person who masters and speaks several languages as a polyglot. <br />
  • The term &#x201C;polyglot programming&#x201D; is generally recognized to have been coined by Neal Ford in late 2006. I&#x2019;ve pulled together here an excerpt of the major points that Neil raises in his blog. Quoting now, &#x201C;We are entering a new era of software development. For most of our (short) history, we&#x2019;ve primarily written code in a single language...but I&#x2019;m beginning to see a time when even the core language...will cease its monoculture...application of the future will take advantage of the polyglot nature of the language world...it&#x2019;s all about choosing the right tool for the job and leveraging it correctly...the times of writing an application in a single general purpose language is over.&#x201D; Of course one of the primary undercurrents here is that we&#x2019;re trying to avoid one of the most common anti-patterns in software development today, that of... <br />
  • THE GOLDEN HAMMER. The golden hammer is nothing more than continually attempting to use the same tool, product, or technique to solve every problem. And I would assert to you that one of the most heavily abused tools in the software development world today is, you guessed it, JAVA. We&#x2019;ve even gone so far as to categorize our development shops as &#x201C;Java shops&#x201D; - meaning that anything that we deliver, regardless of the business domain or problem, will be implemented using Java. <br /> <br /> Now I&#x2019;d like to break down the psychological barriers here a bit by asserting that... <br />
  • ...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an XML document? Written a web page? Used HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that... <br />
  • ...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an XML document? Written a web page? Used HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that... <br />
  • ...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an XML document? Written a web page? Used HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that... <br />
  • ...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an XML document? Written a web page? Used HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that... <br />
  • ...you&#x2019;re really doing this already. Let&#x2019;s have a show of hands. How many of you have worked with on an application recently that persists data into a relational database? OK, how many of you used SQL to do it? How many of you have worked on an application that uses some form of Ajax functionality? How many of you used JavaScript to do it? How many of you have configured a Spring or Java EE application or worked with some form of web services recently? How many of you ended up in an XML document? Written a web page? Used HTML? How many of you have automated your application build, packaging, testing, and/or deployment? How many of you used Ant or Maven to do it? Ant and Maven aren&#x2019;t languages per se, yet the use XML to define a domain-specific language for these types of tasks. So why aren&#x2019;t we resistant to using some combination of these languages in addition to Java? I would argue that... <br />
  • ..the adoption of these additional languages, just like the adoption of Java, C++ before it, and C before that, is driven by critical mass being reached in an area of business or technical demand. Let&#x2019;s examine each of the languages that we just discussed and understand what drove their adoption... <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • SQL - around the time that our industry started developing relational database systems to increase the accuracy and efficiency with which we stored and accessed large amounts of business data, SQL was developed as declarative language that described the expected results of an operation within a relational database management system without specifying the details of the implementation of that operation. Sounds an awful lot like a Domain Specific Language for databases to me. This allowed developers to &#x201C;in theory&#x201D; implement write once, run anywhere at the database level - your VM is your database platform, be it Oracle, MySQL, PostgreSQL, etc. SQL was the &#x201C;killer app&#x201D; for the RDBMS world. <br /> <br /> JavaScript - for years JavaScript was a &#x201C;toy&#x201D; language for most developers. We searched HotScripts.com for something that would disable right-clicks, do form validation, etc. We copied and pasted code, hacked around with it, and basically ignored all of the software development principles that we adhered to when we wrote our &#x201C;real&#x201D; code in Java. Then this big company named Google released their Maps application to the world and we&#x2019;ve never been the same sense. Now our clients are saying &#x201C;why can&#x2019;t we do stuff like that?&#x201D; We became forced to learn JavaScript as a real language and guess what - we found out it&#x2019;s a pretty powerful beast. We&#x2019;re even implementing the entire client-side of applications with it. The arrival of the so-called &#x201C;Web 2.0/Ajax&#x201D; pushed us. <br /> <br /> XML - you can argue that XML was mostly pushed on us. For years developers have searched for a silver bullet solution to the problem of universal data interchange between dissimilar systems. XML was at its birth the latest incarnation of the proposed silver bullet. While we&#x2019;ve continued to argue about whether or not it does the job, a few forward thinking individuals decided &#x201C;Wow, isn&#x2019;t this a great way to configure frameworks and applications?&#x201D; Thus was born ejb-jar.xml, struts-config.xml, and applicationContext.xml. While all of these are slowly eroding away in favor of annotation-based configuration, at the time if you wanted to use EJB, Spring, or one of the 100&#x2019;s of web frameworks out there, you had to get familiar with XML. <br /> <br /> HTML - this one&#x2019;s pretty much a no-brainer. In the late 1990&#x2019;s, the world wide web became uber-hot, and we eventually decided we wanted to use it for more than just fancy &#x201C;under construction&#x201D; graphics. We decided we needed to build web applications! So, since HTML was the lingua franca of the web world, we coders had to learn it to be relevant in the web application age. <br /> <br /> Ant/Maven - those of you who&#x2019;ve ever compiled anything more than the most trivial of C or C++ programs know all about make. Now it&#x2019;s entirely true that you can use make to built Java programs, and as Sun was building the reference implementation of the Servlet specification, which later became Apache Tomcat, they were using a proprietary version of make to do it on the Solaris platform. However, when they wanted to go open source, there was no way of controlling which platform was used to build Tomcat. Ant was created as a simple, platform independent tool to build Tomcat from directives in an XML &#x201C;build file.&#x201D; It was actually released as a standalone product as a bit of an afterthought....but it filled a huge void and is now the build tool used by most Java projects today. Maven is now evolving as the heir apparent to Ant, taking project builds to a higher-level of abstraction than Ant allows. <br /> <br /> The point is, whether it was the lack of a tool for a particular problem or the need for a better or more appropriate tool, something has driven us to the point where we&#x2019;ve been willing to add another language to our toolkit that isn&#x2019;t our core language. <br />
  • So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass? <br />
  • So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass? <br />
  • So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass? <br />
  • So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass? <br />
  • So here are some of the leading candidates to be &#x201C;core&#x201D; polyglot languages of the future on the JVM. Clojure is a dynamically-typed, functional language based on LISP. Jython is the JVM implementation of Python. Groovy is a dynamically-typed language with a simple, Java-like syntax that was born on the JVM. JRuby is the JVM implementation of Ruby. Scala is a statically-typed, multiparadigm language that merges object-oriented and functional concepts into a single, &#x201C;scalable&#x201D; language. What are the factors driving us toward adopting one or more of these languages, and which ones are approaching critical mass? <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

Polyglot OSGi Polyglot OSGi Presentation Transcript

  • Polyglot OSGi Matt Stine
  • Or... “How to sneak your favorite JVM language into the enterprise!”
  • polyglot Many Languages From Ancient Greek πολύγλωττος (poluglōttos), “‘'many-tongued, polyglot'’”), from πολύς (polus), “‘many’”) + γλῶττα (glōtta), “‘'tongue, language'’”)
  • Polyglot Programming We are entering a new era of software development. For most of our (short) history, we've primarily written code in a single language...but I'm beginning to see a time where even the core language...will cease its monoculture...applications of the future will take advantage of the polyglot nature of the language world...it's all about choosing the right tool for the job and leveraging it correctly...the times of writing an application in a single general purpose language is over. - Excerpts from: Neal Ford, “Polyglot Programming” http://memeagora.blogspot.com/2006/12/polyglot- programming.html
  • The Golden Hammer Anti-pattern Using the same tool, product, or technique to solve every problem
  • The Golden Hammer Anti-pattern Using the same tool, product, or technique to solve every problem
  • You’re doing it already...
  • You’re doing it already... SQL
  • You’re doing it already... SQL JavaScript
  • You’re doing it already... SQL JavaScript XML
  • You’re doing it already... SQL JavaScript XML HTML
  • You’re doing it already... SQL JavaScript XML HTML Ant/Maven
  • Adoption of additional languages is driven by critical mass being reached in an area of business or technical demand.
  • Drivers SQL JavaScript XML HTML Ant/Maven
  • Drivers SQL Data Management in RDBMS JavaScript XML HTML Ant/Maven
  • Drivers SQL Data Management in RDBMS JavaScript Web 2.0/Ajax XML HTML Ant/Maven
  • Drivers SQL Data Management in RDBMS JavaScript Web 2.0/Ajax XML Data interchange HTML Ant/Maven
  • Drivers SQL Data Management in RDBMS JavaScript Web 2.0/Ajax XML Data interchange HTML Web 1.0 Ant/Maven
  • Drivers SQL Data Management in RDBMS JavaScript Web 2.0/Ajax XML Data interchange HTML Web 1.0 Ant/Maven Build configuration
  • Drivers?
  • Drivers?
  • Polyglot Drivers
  • Polyglot Drivers Concurrency/Multi-core Hardware
  • Polyglot Drivers Concurrency/Multi-core Hardware Framework Availability
  • Polyglot Drivers Concurrency/Multi-core Hardware Framework Availability Special purpose language constructs/libraries
  • Polyglot Drivers Concurrency/Multi-core Hardware Framework Availability Special purpose language constructs/libraries Essence over Ceremony
  • Polyglot Drivers Concurrency/Multi-core Hardware Framework Availability Special purpose language constructs/libraries Essence over Ceremony Testing
  • Polyglot Drivers Concurrency/Multi-core Hardware Framework Availability Special purpose language constructs/libraries Essence over Ceremony Testing The JVM Itself
  • OSGi The Dynamic Module system for Java
  • OSGi Architecture Application/Bundles Services Security OSGi Platform Service Registry Lifecycle Modules Java Virtual Machine Java Platform Operating System Hardware Inspired by Modular Java (Craig Walls), page 16
  • SOA in a JVM! OSGi Service Registry Dis ice c erv ov sS ers ter Se gis rvi Re ce Service Consumes Service Consumer Bundle Bundle Inspired by Modular Java (Craig Walls), page 17
  • Modularity...how?
  • Modularity...how? Encapsulation
  • Modularity...how? Encapsulation Service Registry
  • Modularity...how? Encapsulation Service Registry Versioning
  • Bundle Versioning Foo 1.0.0 Bar Qib 1.0.2 2.0.1 Zab Zab 1.0.4 2.1.3 Inspired by Modular Java (Craig Walls), page 18
  • Modularity...how? Encapsulation Service Registry Versioning
  • Modularity...how? Encapsulation Service Registry Versioning Dynamism/Lifecycle
  • Modularity...how? Encapsulation Service Registry Versioning Dynamism/Lifecycle Strong-Naming
  • OSGi Implementations
  • OSGi Implementations Equinox
  • PAX Tools for OSGi
  • PaxConstruct
  • PaxConstruct Script-oriented toolkit for OSGi development
  • PaxConstruct Script-oriented toolkit for OSGi development Similar to Rails/Grails development model
  • PaxConstruct Script-oriented toolkit for OSGi development Similar to Rails/Grails development model Built on Maven 2
  • PaxConstruct Script-oriented toolkit for OSGi development Similar to Rails/Grails development model Built on Maven 2
  • PaxRunner
  • PaxRunner OSGi framework launcher
  • PaxRunner OSGi framework launcher Facilitates quick start OSGi exploration
  • PaxRunner OSGi framework launcher Facilitates quick start OSGi exploration Facilitates swapping OSGi platforms (works with all major open source implementations)
  • PaxRunner OSGi framework launcher Facilitates quick start OSGi exploration Facilitates swapping OSGi platforms (works with all major open source implementations) Facilitates provisioning OSGi bundles from multiple sources
  • PaxRunner OSGi framework launcher Facilitates quick start OSGi exploration Facilitates swapping OSGi platforms (works with all major open source implementations) Facilitates provisioning OSGi bundles from multiple sources Magic behind “pax-provision” and PaxExam
  • PaxExam
  • PaxExam Testing toolkit for OSGi
  • PaxExam Testing toolkit for OSGi Facilitates in-container integration testing of bundles
  • PaxExam Testing toolkit for OSGi Facilitates in-container integration testing of bundles Flow:
  • PaxExam Testing toolkit for OSGi Facilitates in-container integration testing of bundles Flow: Starts OSGi container of choice
  • PaxExam Testing toolkit for OSGi Facilitates in-container integration testing of bundles Flow: Starts OSGi container of choice Provisions and starts selected bundles
  • PaxExam Testing toolkit for OSGi Facilitates in-container integration testing of bundles Flow: Starts OSGi container of choice Provisions and starts selected bundles Injects OSGi BundleContext to your JUnit test
  • PaxExam Testing toolkit for OSGi Facilitates in-container integration testing of bundles Flow: Starts OSGi container of choice Provisions and starts selected bundles Injects OSGi BundleContext to your JUnit test Executes a test method
  • PaxExam Testing toolkit for OSGi Facilitates in-container integration testing of bundles Flow: Starts OSGi container of choice Provisions and starts selected bundles Injects OSGi BundleContext to your JUnit test Executes a test method Rinse and repeat until done!
  • Why Polyglot OSGi?
  • Why Polyglot OSGi? Java Java Service Java Client Service Implementation Client Module Server Module
  • Why Polyglot OSGi? Java Java Service Java Client Service Implementation Client Module Server Module
  • Why Polyglot OSGi? Java Java Service Java Client Service Implementation Client Module Server Module
  • Why Polyglot OSGi? Java Java Service Java Client Service Implementation Client Module Server Module
  • Why Polyglot OSGi? Java Groovy Service Java Service Java Client Service Implementation Client Module Server Module
  • Why Polyglot OSGi? Java GroovyService Scala Service Java Service Java Client Service Implementation Client Module Server Module
  • Why Polyglot OSGi? Java GroovyService Clojure Service Scala Service Java Java Client Service Implementation Client Module Server Module
  • Why Polyglot OSGi? Java GroovyService Clojure Service JRubyService Scala Service Java Java Client Service Implementation Client Module Server Module
  • The line must be drawn HERE!
  • Polyglot OSGi Pros
  • Polyglot OSGi Pros Manage Risk
  • Polyglot OSGi Pros Manage Risk Encapsulation
  • Polyglot OSGi Pros Manage Risk Encapsulation Decoupled Architecture
  • Polyglot OSGi Pros Manage Risk Encapsulation Decoupled Architecture Java = JVM Lingua Franca
  • Polyglot OSGi Cons
  • Polyglot OSGi Cons Constant Java translation at boundary
  • Polyglot OSGi Cons Constant Java translation at boundary Less idiomatic code
  • Polyglot OSGi Cons Constant Java translation at boundary Less idiomatic code Language / OSGi mismatch
  • Polyglot OSGi Cons Constant Java translation at boundary Less idiomatic code Language / OSGi mismatch Not a silver bullet for large teams with few polyglots
  • A Polylgot OSGi Vending Machine
  • PGOVM Specification Valid Actions: NICKLE, DIME, QUARTER, DOLLAR - insert money COIN RETURN - returns all inserted money SERVICE - a service person opens the machine and sets the available change and items GET-A, GET-B, GET-C - select item A ($.65), B ($1), or C ($1.50)
  • PGOVM Specification Valid Responses: NICKLE, DIME, QUARTER - return coin A, B, C - vend item A, B, or C Track state: available items (count, price, selector) available change (# of nickles, dimes, quarters, dollars available) currently inserted money
  • PGOVM Specification Example Traces: Buy B with exact change: Q, Q, Q, Q, GET-B -> B Add change, hit coin return: Q, Q, COIN-RETURN -> Q, Q Buy A without exact change (return $.35) DOLLAR, GET-A -> A, Q, D
  • Why this spec?
  • Why this spec? Simple to understand, yet...
  • Why this spec? Simple to understand, yet... ...demonstrates reasonable complexity one might find in a real application
  • Why this spec? Simple to understand, yet... ...demonstrates reasonable complexity one might find in a real application Algorithms suitable for showcasing language features
  • Goals Implement a Java interface contract for the spec Test-drive a Java implementation Use tests as a contract to implement in: Groovy Scala Clojure Build a Spring MVC application to exercise different vending machines
  • DEMO http://localhost:8080/pgovm/vm.html
  • Java Contract
  • PaxExam Tests
  • Run Test Demo
  • Groovy Implementation
  • Scala Implementation
  • Scala Gotchas
  • Scala Gotchas Scala in Maven Central is NOT an OSGi Bundle!
  • Scala Gotchas Scala in Maven Central is NOT an OSGi Bundle! Can download from http://scala-lang.org.
  • Scala Gotchas Scala in Maven Central is NOT an OSGi Bundle! Can download from http://scala-lang.org. Swap it out manually...
  • Scala Gotchas Scala in Maven Central is NOT an OSGi Bundle! Can download from http://scala-lang.org. Swap it out manually... ...however...
  • Scala Gotchas Scala in Maven Central is NOT an OSGi Bundle! Can download from http://scala-lang.org. Swap it out manually... ...however... won’t work with Maven anymore!
  • Scala Gotchas Scala in Maven Central is NOT an OSGi Bundle! Can download from http://scala-lang.org. Swap it out manually... ...however... won’t work with Maven anymore! Use Groovy script to swap out Scala jars.
  • Clojure Implementation
  • Clojure Gotchas
  • Clojure Gotchas Clojure also not available as an OSGi bundle!
  • Clojure Gotchas Clojure also not available as an OSGi bundle! Use Pax Construct to embed in bundle for Clojure implementation.
  • Clojure Gotchas Clojure also not available as an OSGi bundle! Use Pax Construct to embed in bundle for Clojure implementation. Mixed experiences out there with trying to share a common Clojure bundle.
  • Clojure Gotchas Clojure also not available as an OSGi bundle! Use Pax Construct to embed in bundle for Clojure implementation. Mixed experiences out there with trying to share a common Clojure bundle. OGEE Project (Roman Roelofsen) http://ogeesource.org
  • Clojure Gotchas
  • Clojure Gotchas Not OSGi related, but...
  • Clojure Gotchas Not OSGi related, but... Maven Clojure Plugin won’t seem to compile Clojure first, so if your Java code depends on Clojure code...
  • Clojure Gotchas Not OSGi related, but... Maven Clojure Plugin won’t seem to compile Clojure first, so if your Java code depends on Clojure code... Must run “mvn clojure:compile” first
  • Spring MVC Web Implementation
  • That’s all folks! Please fill out your evaluations!