Java at 20

Remembering what the programming world was like in 1995 is no easy task. Object-oriented programming, for one, was an accepted but seldom practiced paradigm, with much of what passed as so-called object-oriented programs being little more than rebranded C code that used >> instead of printf and class instead of struct. The programs we wrote those days routinely dumped core due to pointer arithmetic errors or ran out of memory due to leaks. Source code could barely be ported between different versions of Unix. Running the same binary on different processors and operating systems was crazy talk.

Java changed all that. While platform-dependent, manually allocated, procedural C code will continue to be with us for the next 20 years at least, Java proved this was a choice, not a requirement. For the first time, we began writing real production code in a cross-platform, garbage-collected, object-oriented language; and we liked it ... millions of us. Languages that have come after Java, most notably C#, have had to clear the new higher bar for developer productivity that Java established.

James Gosling, Mike Sheridan, Patrick Naughton, and the other programmers on Sun’s Green Project did not invent most of the important technologies that Java brought into widespread use. Most of the key features they included in what was then known as Oak found its origins elsewhere:

• A base Object class from which all classes descend? Smalltalk.
• Strong static type-checking at compile time? Ada.
• Multiple interface, single implementation inheritance? Objective-C.
• Inline documentation? CWeb.
• Cross-platform virtual machine and byte code with just-in-time compilation? Smalltalk again, especially Sun’s Self dialect.
• Garbage collection? Lisp.
• Primitive types and control structures? C.
• Dual type system with non-object primitive types for performance? C++.

Read the entire article: http://www.javaworld.com/article/2925496/core-java/java-at-20-how-java-changed-programming-forever.html

MIPS

First of all, this morning I found out that exist two different MIPS in this world.

First MIPS is a reduced instruction set computer (RISC) instruction set architecture (ISA) developed by MIPS Technologies (formerly MIPS Computer Systems, Inc.).

The other MIPS is a software product. I wanted to talk about this one because I had to face it at my workplace. This MIPS is from Management & Information Processing Services. They said that this software is made to help you in your Management activities.

From my experience at my workplace this software help you to annoying you. It is ugly and difficult to use. It is not oriented to user. It is made to build another ugly thinks. MIPS solutions doesn't help you, MIPS generates a lot of new problems. Here we have built something very nice with webserver and external database using AJAX, jQuery for front-end for a wonderful experience for the final users. But, MIPS team came with something ugly and nonsense solution. They have been chosen because they are MIPS even their solution is a big problem for users teams. Because the IT management is old and they don't understand that we are in XXI century.

And how can you have trust in this kind of software when they have a website like this? http://www.mipssoftware.com/
* built like has been made in 1992.
* ugly and non-friendly structure
* unfinished texts
* Underconstruction ???? Since 2011.

STS

I've tried to make a Spring Java project. I tried and tried last week, but today I've discovered this: STS. Which is an Eclipse extension easy to build Spring Projects.

HTTP/2: A jump-start for Java developers

HTTP/2 was approved in February 2015 as the successor to the original web communication protocol. While it is in the last stages of finalization, the standard has already been implemented by early adopters such as Jetty and Netty, and will be incorporated into Servlet 4.0. Find out how HTTP/2 renovates HTTP's text-based protocol for better latency, then see techniques like server push, streaming, multiplexing, and header compression implemented in a client-server example using Jetty.

High-speed browser networking

In the early days of the World Wide Web, Internet connection bandwidth was the most important limiting factor for a faster browsing experience. That has changed in the years since, and these days many consumers use broadband technologies for Internet access. As of 2014, Akamai's State of the Internet report showed that the average connection speed for customers in the United States exceeded 11 Mbit/s.
As Internet connection speeds have increased, the importance of latency to web application performance has become more apparent. When the web was new, the delay in sending a request and waiting for a response was much less than the total time to download all of the response data, but today that is no longer the case. "High bandwidth equals high speed" is no longer a valid maxim, but that doesn't mean we can ignore the importance of bandwidth. For use cases that require bulk data transfer such as video streaming or large downloads, bandwidth is still a roadblock. In contrast to web pages, these types of content use long-running connections, which stream a constant flow of data. Such use cases are bandwidth bound in general.

Read the entire article here: http://www.javaworld.com/article/2916548/java-web-development/http-2-for-java-developers.html

Java: The once and future king of Internet programming

Built for embedded computing and streamlined for real-time, here's why Java is the language of IoT

What is Java to you? A programming language you learned in college? The lingua franca of corporate IT? Would you believe that Java is poised to dominate the next explosion of the Internet? Built for embedded computing and streamlined for real-time applications, here's why Java is the language for IoT.

The years from 1969 to present saw networked devices balloon from four university computers connected via the ARPANET to about two billion humans frequently accessing the Internet today. In the near future that number will exponentially multiply again, from a couple billion networked devices to tens of billions of embedded processors. Every aspect of our lives will be connected by networked devices: homes, workplaces, vehicles, appliances, tools, toys --you name it.

While chatter about the Internet of Things (IoT) includes a component of fashionable hype, the underlying reality is that imminent changes in Internet growth will make previous generations of computing look trivial by comparison. IoT is not only here to stay; it's here to change everything. Consider the following timeline, which shows previous tipping points for the Internet as we have known it:

• 1982-1989: Birth of the TCP/IP internet.
• 1985-1989: Commercialization of the Internet begins.
• 1990-1991: Advent of the World Wide Web.
• 1990-1998: Conventional desktop computers re-engineered as intrinsicallynetworked devices.
• 1996-present: Slowly but surely, we enter the age of global domination by mobile networked devices (aka IoT).

Complementary technologies that enable IoT are coming online now. HTTP/2 is a crucial networking protocol that has been updated, in part, to accommodate machine-to-machine communications. Thingsee is an example of a developer kit for the kind of hardware that IoT will demand.

Silicon Valley sage Tim O'Reilly has emphasized that the result will not be just the usual caricature of pointless connections from coffee machines or refrigerators to the 'Net at large. With enough sensors and automation, IoT is really about human augmentation. Java will be a workhorse in that coming disruption.

How IoT works

In September 2014, Andrew C. Oliver wrote that at an implementation level IoT is about teamwork. In this case, the teamwork involves both humans and computers.

As devices communicate not just with human consumers, but with other devices, fundamentally new capabilities emerge. It's not only that your refrigerator will know you have run out of tomatoes, but that it can place an order for more on your behalf. The success of pervasive computing will be that it recedes into the background, working out facts and events and remedies with other connected devices. Only executive-level results will be communicated to human consumers. The triumph of IoT will be in all the things that we no longer have to think about, even as they are seamlessly done for us.

The most mundane examples are the most telling. Leave aside just-in-time agricultural pest treatments, miniaturized bomb-sniffers, improved medical diagnostic technology, or similarly impressive applications of IoT in recent news. Think instead of the humble vending machine -- one that's properly stocked, well maintained, and always silently awaiting your command.

When you place your bills in a vending machine and push buttons to indicate your purchase, several mechanisms interact to ensure the satisfaction of your hunger. You don't have to understand or agree with all the details of implementation; your stomach is just happy with the results. Now, we have IoT-enabled vending machines. When you make a purchase from an IoT-enabled vending machine, your purchase triggers actions spanning the globe to keep inventory in balance and parts well-maintained, at a total cost 30 percent lower than the pre-IoT model.

Java for embedded computing

Few people today realize that Java began as a language for embedded computing. Its earliest versions specifically targeted home appliances such as television set-top interfaces. Communication between devices was central to James Gosling's original vision for Java, and he envisioned it being used for not only device-to-consumer but device-to-device communication. Twenty years later, those original design strengths are ready to support the Internet of Things.

Java's ubiquity also makes it a good fit for IoT. Massive resources worldwide are invested in transmitting Java to a new generation of programmers and ensuring that it is maintained to support all the production systems that rely on it. Hundreds of thousands of successful applications and systems already attest to Java's capabilities.

For developers exploring embedded programming it is important to distinguish the parts of the Java platform. Nothing about how you code or read programs needs to change for embedded programming: good Java programmers can read embedded source code just as easily as they do the source for typical desktop enterprise applications. The libraries, and especially the development (and testing) environments, are specialized for embedded Java programming, however. Just be sure that you have the right toolchain for the embedded environment you target.

Java embedded programming in 2015

Java already had the right stuff to make embedded programming possible in 1996, but it lacked momentum. Today that momentum is gathering fast, and an ecosystem of Java standards and tools for embedded programming is ready to leverage it.

Between 2000 and 2010, it was generally true that Java-based embedded or "micro" computing centered on J2ME(Jave 2 Platform, Micro Edition). Now, Java Platform, Micro Edition, or Java ME, is the standard runtime environment for embedded applications. While Java ME and its concepts --especially profiles andconfigurations --remain crucial, mobile Java developers tend to focus more on Android, and HTML5 for user interfaces. Cellular telephone handsets are the most visible embedded computers, and roughly four out of five mobiles sold now are based on Android. (Although Android supports Java ME, the two have different product lifecycles, and it's not entirely clear who will decide what the next generation of application environments for practical embedded devices will be.)

Profiles and configurations are crucial concepts in embedded programming. Anembedded profile such as MIDP is a collection of APIs supported on devices of interest. A configuration is a framework specification. While not strictly true it can be useful to think of profiles as belonging to configurations, including most prominently the CLDC or Connected Limited Device Configuration. (Also see "Jim Connors' Weblog" to learn more about profiles and configurations applicable to IoT.)

In addition to Java ME's profiles and configurations, a handful of enterprise Java technologies hold potential for embedded development. Java Management Extensions (JMX) is used for distributed resource management and monitoring and could one day complement embedded definitions neatly. Real-time Java also holds an important place in embedded programming for IoT.

Java's real-time model and tools

Embedded applications connected to sensors and effectors in medical, transportation, manufacturing, and other domains often have important real-time requirements. Predictable, correct results from heart pacemakers, engine controllers, pipeline valves, and so on are matters of life and death, not just annoying stack tracebacks.

While James Gosling intended Java to fulfill common real-time requirements, real-time computations weren't a strength of Java in its early years. In particular, many Java runtimes had a reputation for unreliability, or at least inconsistency in how they handled garbage collection. Real-Time Specification for Java (RTSJ) and related standards addressed temporal indeterminacy with support for periodic and sporadic task scheduling, task deadlines and CPU time budgets, garbage-collecting threads, and allowances that enable certain tasks to avoid garbage collection delays. RTSJ was approved in 2002 and has been implemented for a number of Java VMs.

Although RTSJ was officially listed as dormant in the Java Community Process until February 2015, specification experts have been actively at work refining and updating it throughout the last decade. As an example, JamaicaVM is an RTSJ implementation supported by aicas GmbH, available at no charge for educational and other non-commercial use.

More recently, Oracle has promoted Java SE for real-time systems, suggesting that Java SE has been enhanced sufficiently to meet soft real-time requirements. Soft here has at least two distinct related meanings. One is that requirements have to do with average behavior; for instance, it's good enough that an average bank transaction will post within 300 milliseconds. This is in contrast to hard real-time requirements, such as the requirement that a particular locomotive-switching solenoid close at worst within one-and-a-quarter seconds of the application receiving a specific alarm. The most important requirement for hard real-time systems, in this sense, is that the worst case must be predictable.

Soft real-time is good enough for many embedded and IoT applications. For applications that require hard real-time support, Java developers largely turn to JSR-302: Safety Critical Java Technology. This spec is a subset of the Real-Time Specification for Java, and parts of it depend on the CLDC. Among other features, Safety-Critical Java defines its own concurrency model and real-time threads. The Open Group industry consortium originally began work on Safety-Critical Java in 2003. Asked about the spec's status, JSR-302 specification lead Doug Locke estimated that its long gestation will lead to an approved specification this spring, with a reference implementation possible by early May 2015.

Next up in Java embedded

Java holds much promise for embedded programming, and there is work to be done in order to enable it to meet the coming explosion of demand and possibility in IoT.Tens of billions of Java-capable devices will go into use as part of the IoT network over the next few years. My next article on this topic will feature specific examples of programming for embedded Java environments in both hobbyist and commercial contexts, along with a deeper explanation of why RTSJ 2.0 will impact Java far beyond traditional domains for real-time programming.