fbpx

Made in USA: Enterprise Application Services

Ringing PhoneCall Today!817-210-4042

Java Archives - Ayoka - Made in USA Enterprise Application Services

Custom Java Software Development Services and the Chrome Problem

November 27, 2015
|
0 Comments
|
Here’s why we expect an uptick in demand for custom Java software development services after the Chrome announcement.

The custom Java software development services community is abuzz with the news that the Chrome web browser’s newest release (version 42) has a default setting that blocks the Java plugin. As of September 2015, even advanced users won’t be able to alter their settings to enable Java and other extensions, such as Silverlight, that use the deprecated NPAPI.

Why the Change?java software development services

Google’s stated goal for un-publishing this API for Chrome is to reduce the risk that certain known vulnerabilities in Java might be exploited. Other reasons to eliminate the 1990s plugin technology include its tendencies to hang or crash the browser and its unnecessarily complex code. Firefox and Safari, along with older versions of IE, still support NPAPI for now. However, major players like Netflix that previously relied on Silverlight have switched to other options such as Encrypted Media Extensions that meet modern web standards.

Oracle’s response to the shutout of the Java plugin has yet to be fully determined. Alex Russell, an engineer on the Chrome team at Google, offered his opinion on what should come next: “As I’m on the Chrome team at Google and don’t have any specific knowledge of Oracle’s plans, I can’t comment on what they might do, but I can say the we would welcome a more-secure (perhaps Pepper/NaCL based) Java experience for users.”

What NPAPI Shutdown Means for Business Software

This change could have significant ramifications for companies that use browser-based web applications as part of their business. For internal apps that are used by employees, specifying which browsers should be used for work purposes is a short-term workaround. But for customer facing apps that will be used on the browser of the user’s choice, some re-engineering and modernization will be required.

Are you concerned about the impact of NPAPI deprecation for your business web applications? Contact Ayoka at 817-210-4042 to review your options.

Enterprises Still Need a Good Java Software Development Company

October 1, 2015
|
0 Comments
|

Enterprises Still Need a Good Java Software Development Company

At Ayoka, we offer solutions in many programming languages but we’re still well-known as a Java software development company. That’s because Java-related services are requested year after year. Businesses throughout Texas rely on this powerful programming language to keep their applications running. Here’s why.

Java Is Deeply Ingrainedjava development company

The “death of Java” has been predicted by various bloggers and all of them have been wrong. While Java is not something an average consumer might miss if they disable a few web plugins, server side Java and the JVM still serve as the foundation of much enterprise software architecture. Recent security concerns have been addressed, and the newer releases of Java include many of the features of trendier languages (such as the lambda expressions that are a favorite feature in C#).

Java Spawns New Technology

Contrary to what you might suppose, JavaScript did not actually start as a part of the Java language and diverge from there. It got its name upon the introduction of Java runtime into the Netscape browser when LiveScript was rebranded as JavaScript. But Java for Android is a legitimate forking of the Java language into very new territory. Given Android’s continued popularity in the smart device field, Java for mobile is definitely not a legacy technology—it’s fully modern.

Java Plays Well with Others

Because of Java’s entrenched position in the world of business software, programmers have come up with many ingenious ways to combine it with other languages and frameworks. These mashups include Jython (Java and Python) and Jruby (Java and Ruby). There are also a wide variety of ways to bridge Java with C#, PHP, .NET and other programming methods to get the best of both worlds. Simply put, Java has proven flexible and responsive enough to integrate with newer technology. This propensity for change has ensured that Java remains a relevant player.

Have questions about how to get the most out of your organization’s Java-based software? Contact Ayoka at 817-210-4042.

Interoperability Made Easier

August 18, 2009
|
0 Comments
|

Interoperability is becoming a quality of greater importance for software or IT products in today’s market. Interoperability is the ability of systems or products to exchange services so as to operate effectively together. There are many scenarios that could require an application written in specific language to call a module or component developed in another language. Irrespective of the scenario, you need to solve the problem of interoperability.

In this blog I would like to introduce you developers to few tools that exist in the market which would help you achieve your goal, which is solving the interoperability issue. Interoperability can be achieved in two ways:

  • Web Services
  • Bridging

You might have heard a lot about web service and terms like remote procedure call (RPC), Simple Object Access Protocol (SOAP), Web Service Definition Language (WSDL) etc. I am not going to go over that here today but rather the second one which is bridging.

.NET/Java Interoperability

JNBridge is a Java and .NET interoperability tool that allows you to access your entire object-oriented API from the other side, in the same process or across a network. JNBridge creates Interoperability Bridge by generating a set of proxies that expose the classes API. When deployed the .NET classes communicate with the Java classes via the generated proxy classes or vice-versa. The .NET code runs on a .NET CLR and Java code runs on any conformant JVM. JNBridge offers a quick solution to Java/.NET divide and good integration with Visual Studio environment.

Adobe Air/Java Interoperability

Merapi, a messaging bridge, is a Adobe Air and Java interoperability tool that enables Adobe Air applications to communicate with other Java applications that the user has installed on their computer by passing objects between the applications. Developers can write Java application for their Air applications using a light weight and straightforward API. Java programs treat Merapi as a bridge to run AIR applications and vice-versa.
Another interesting tool that provides a developer with a toolkit of commands to extend system capabilities of your AIR application is Shu. By wrapping your AIR application, Shu player solves some of the problems faced by AIR applications such as opening files in native applications, executing other applications. As of now they support only Windows and MAC systems.

Java/COM Interoperability

ComfyJ is Java-COM interoperability tool which allows developers to integrate their Java applications with COM/OLE/ActiveX libraries. ComfyJ is a communication bridge between Java and COM, based on JNIWrapper technology, enabling bidirectional communication between the Java platform and COM technologies. It allows the Java objects to be implemented as COM objects. ComfyJ allows registering of created Java COM servers that can then be used by other COM applications.

Differences between Java and ActionScript3

July 28, 2009
|
0 Comments
|

Recently I set out to start writing a Adobe Flex application, which uses ActionScript3 as the native language. I looked for advice on where to start and a few people told me it’s a lot like Java, and that I should just start writing Java code and the few differences would be picked up by the compiler. So I started my project, and I’ve found for the most part, my advisors were correct: ActionScript3 is very similar to Java. But there are differences.

One of the main differences, one that you’ll either love or you’ll hate, is optional static typing. Basically you are not forced to type your variables like you are in Java, but you have the liberty to do so if you want. Here is the equivalent code in Java and ActionScript3:

Java:
public class TestVariableDefinitions {

public String id;
public int numOccurances;
public Object xmlData;
public Object jsonData;

// …

ActionScript:
public class TestVariableDefinitions
{
// these two are statically typed
public var id:String;
public var numOccurances:int;

// these two are dynamically typed
public var xmlData;
public var jsonData:*;

The second difference, which can be seen in the code example above, is syntax:

  • Variables are defined with the var keyword
  • Variable types are optional (dynamic typing)
  • Methods are declared explicitly with the function keyword
  • Method header type hints are signified with a colon, not a space

Another difference is in the line breaks for braces. In ActionScript3, it is convention that braces for methods, classes, loops, etc., all get their own line, whereas in Java, the opening braces are on the same line as the header. You can see this in the code example above.

Last is the concept of getters and setters. While the Java syntax works in ActionScript3, there is a new syntax that I feel helps readability slightly, and acts as a “magic” method. This is demonstrated below:

Java:

public class TestVariableDefinitions {

public static String id;

public static void main(String[] args){
System.out.println(“The ID is ” + getId());
}

public static String getId(){
return TestVariableDefinitions.id;
}
}

Direct Translation to ActionScript3:
public class TestVariableDefinitions
{
public var id:String;

public function TestVariableDefinitions() {
trace(“The ID is ” + getId());
}

public function getId():String {
return id;
}

}

Using alternate syntax:
public class TestVariableDefinitions
{
public var _id:String;

public function TestVariableDefinitions() {
trace(“The ID is ” + id);
}

public function get id():String {
return _id;
}

}

Notice how we were able to access a magic variable named id, without that variable actually having to exist. The getter (and setter), automatically picks up on the fact that you are trying to access a special property of the object. This works similarly with setters:

public class TestVariableDefinitions
{
public var _id:String;

public function TestVariableDefinitions() {
var myNumber:int = 5;
id = 5;
}

public function set id(number:int) {
_id = number;
}

}

Note that it is not possible (because it wouldn’t make any sense) to have a class property and magic setter/getter referring to the same property name.

There are other small differences, but these are the ones I found to be most prominent. If there are any big differences between the two languages that you feel I missed, feel free to share.