Java came up with "write once run everywhere".
How to do the trick with all the frameworks in the long term?
I wrote an application with JSF and richfaces a few years ago. Browsers have evolved and introduced new features and of course new bugs. Now the application still runs, and sometimes it shows javascript errors from the underlying libraries.
Do we really have to reimplement a finsihed application (no use cases to add) due to technical 'improvements' ?
EDIT: The application I mentioned was just an example. Same things easily happen if vendors change licenses. (Oracle could charge for a vm and open vm is not compatible with you application stack etc.)
Even if we believe "write once, run anywhere", it's not quite the same thing as eternal backward compatibility. Pragmatically, you must expect future versions of frameworks to change some things. Sometimes this will be the removal of what used to be guaranteed behavior (the worst kind of change), other times bugs in your code will go unnoticed until some future version of the library reveals that you were relying on an implementation detail that wasn't guaranteed. More rarely, your old code will reveal a novel bug in the latest version.
In an ideal world, we'd write code which relies only on guaranteed behavior, and guarantees would never be removed, and hence valid code would continue to work forever. Against that, it's hard to prove that your program is totally correct, and the language/framework/library developers make decisions about whether they can add the improvements they want to, while retaining perfect compatibility.
For compatibility to win the argument, the original API has to be strong enough and stable enough to survive without disruptive changes. If it isn't, then either non-compatible changes will be made, or else the API will be abandoned entirely. Either way, your program won't run any more unless you have an old version tucked away somewhere to run it on.
You ask how to do the trick - it requires either really good and somewhat lucky interface design in the first place to allow all the extensions you come up with later, or else a firm commitment and a "business case" (or non-business motive) to support the "old" version indefinitely. For example, Python 3 isn't compatible with Python 2, but Python 2 is still actively supported with updates, so old Python code still runs. C99 removes only a few features of C89, and if all else fails C89 compilers are still actively maintained. Browsers support a thousand and one old versions and non-standard quirks of HTML. I don't know how JSF and richfaces compare to those, or how much they output pages that rely on support for "old" (or quirky) HTML/CSS/Javascript behavior from the client.
So it can happen, at least for a while. But there are IE6 features which are no longer available in any browser that's safe to let out on the web (I guess you could run IE6 in a sandboxed VM, or on a machine you don't care about), so it's a question of what you depended on in the first place. Could it have been predicted that proprietary browser extensions would be dropped like a stone in future versions? Probably, but could those IE6 app-writers have achieved what they wanted to using proper standards available at the time? Not always. Even for those who didn't get involved with IE6, if your app falls into a similar trap, you're out of luck.
I don't suppose anyone can seriously promise "run anywhere, forever". Sooner or later Linux and Windows and MacOS will all be obsolete, new OSes will come out, and no one will bother to write JVMs for them, so none of your Java apps will run any more. (I have an old MS DOS game that I thought was way cool but it won't run under a Windows DOS box. THe company came out with a Windows version but they seriously redesigned the game and, in my humble opinion, destroyed everything that made it fun. Bummer man.)
In the meantime, upward compatibility of new versions is a great thing, but every now and then vendors decide that it's just too much trouble.
It seems that you are speaking not about application but about applet (because you mentioned java script). Moreover this is an applet that calls javascript from page where it is deployed. In this case it is not exactly pure java. It sounds like to call platform dependent command line using Runtime.exec(), then change OS and complain that application does not work.
Or probably I did not understand correctly you use-case?
Programming languages and technologies evolve. Speaking broadly, if a web app is pretty basic, it may be able to take updates without requiring many changes.
Java-based languages seem to update less frequently than languages in the Microsoft stack. JSF 2 has some big changes over previous versions, however, and Richfaces 3.x apps will require migration if you want to use Richfaces 4.x.
As a workaround, you don't always have to upgrade; there are plenty of sites written in older languages (classic ASP for one), deployed and still running happily.
Related
I don't know how to fix this error can you please help me?
Execution failed for task ':app:processDebugMainManifest'.
Unable to make field private final java.lang.String java.io.File.path accessible: module java.base does not "opens java.io" to unnamed module #203e7cb0
I am very grateful for every answer.
Explanation: Your tooling (The code that powers the processDebugMainManifest task, which I think is the Android Build System) is trying to do a task in java, but this task is simply not available in public APIs. Instead of accepting that it is impossible to write an Android Build system in java in the way the android team wanted, the devs of android instead realised that JVMs can do it, it's just that there is no public accesspoint to ask it to do it. Thus, they decided to use the not-intended-for-public-consumption part, given that without doing this they can't do the job at all, and have accepted the maintenance burden.
Unfortunately, Team OpenJDK is aggressively locking this stuff down, even though usually there is no ready alternative (as in, the right order is obviously to first make an inventory of commonly used private APIs, then make suitable alternatives for the top 95% of usage, and then proceed with lockdown, though not in such a heavyhanded fashion as they have chosen to do - team OpenJDK hasn't done this)1.
That's what this warning means: The java release you use is no longer 'allowing' it. This java release has broken processDebugMainManifest for a dubious reason. Likely whatever pDMM is trying to do is now completely impossible in java releases that locked this down and thus...
Solution:
Downgrade your java.
Download AdoptOpenJDK's OpenJDK8 which is free and open source.
In particular when doing android dev this is generally a good idea. Android has never worked well with newer javas; neither the features introduced in the language, nor the additions to the core libs (as android has its own implementation of them). The existence of this courtcase probably isn't helping things along.
[1] I have oversimplified a tad; for example, there are a few methods in sun.misc.Unsafe which OpenJDK openly states are sometimes neccessary and they are more or less committed to keeping Unsafe available until they've found adequate alternatives for all such uses (if only they had that attitude for a few more commonly used internal bits, there wouldn't be such a gulf between the community and the openjdk team). Also, there is common 'internal API' usage which is indeed inappropriate, such as the widespread use of sun.misc.BASE64Encoder which no library/tool/app ever should have used, and for which alternatives have always been available, and these days, alternatives are baked into the JDK itself: Team OpenJDK's decision to effectively eliminate both direct access to BASE64Encoder as well as shutting down all attempts to work around the lack of direct access are therefore probably justified. It's shades of gray: Whenever private API use occurs, part of the blame lies with the OpenJDK for not having an alternative, and part of the blame lies with the library/tool/app for envisioning the way it works in a way that can't be done (easily) without relying on internals that weren't designed for public use like this. My impression is that the core OpenJDK contributors are wildly misjudging themselves on this divide and basically placing virtually all blame not on them but on the library builders, and aren't giving sensible solutions other than 'pull your entire tool/library/app from existence, you should never have written it'. Thus, I'm faring on statistics here, but it is quite likely the explanation of whatever's going on here: The OpenJDK is locking down the ability to do this stuff without having a reasonable alternative, therefore processDebugMainManifest, even the most recent version, would still cause this error and they can't fix this error without rewriting a ton of code and completely changing how it works for the users of the Android Build infrastructure.
Some insights (including that vibe that OpenJDK core contributors seem to feel the blame lies almost entirely with apps/libraries/tools) is on display on this Inside Java podcast with Alan Bateman.
I am a hobbyist java programmer using NetBeans IDE. A problem I face with programming in Java is choosing the correct target JRE version. I understand that most of my friends have at least java 6, but few have a totally up-to-date version with which I compile. I know how to compile for a particular target run-time environment on NetBeans; the problem is that by using an earlier target release of Java, the compiler expects code written in that version.
For a specific example, I occasionally use a Java 8 lambda instead of a new Runnable(){}, however the compiler (or at least NetBeans) doesn't accept this 'modern' code. Another example is the use of the diamond operator, or the use of multiple-exception catch statement, neither of which are supported by Java 6. The language evolves and the compiler evolves, but older versions of Java cannot handle the change. To distribute my code, I am forced to use what some might consider outdated code.
My question is: Is it considered good practice or common practice to write Java for an outdated target version to provide compatibility? Is there some form of 'translator' or cross-compiler for Java code?
My question is: Is it considered good practice or common practice to write Java for an outdated target version to provide compatibility?
It is common practice.
Whether it is "good practice" or not, is highly context dependent. There is a pragmatic trade-off between supporting older applications whose developers don't want (or can't) upgrade, and holding back the development of your application by not making use of new (and presumably beneficial) features.
There is no universal "best" answer.
Is there some form of 'translator' or cross-compiler for Java code?
Effectively, no. For old versions of Java there were "retro-weavers" which allowed you to run "newer" Java on "older" platforms. However, this approach seems to have died out by Java 6.
To answer your first question, it really depends on the standards set by the company/office that you are working for.
From my experience, most of time big companies tries to stay with matured and well established development platforms, they might not give the cutting edge features of the new language, but the companies want the base platforms to be stable and secure first. And if the codebase is large and the project has been in development for a long time, they normally don't bother jumping into the new platform, since that means they might have to invest more resources to rewriting/refactoring a lot of code, which is not always economically lucrative.
I love using those features that you mentioned in my personal projects, but in my office works we are still using JDK6.
As for the second question, I think there are no workable things at this moment that can do the "translation" that you mentioned.
From my experience this isn't a big problem in the industry. Java is used mostly on the server, not so much on the desktop. And to setup a server with the required Java version is not a big deal. For desktop applications I also seen the approach to ship the JRE with the application. It is a little bit ugly to ship a small application (let's say 5 MB) with a 60 MB JRE, but in the "enterprise environment" it doesn't matter and is a practical way to provide the correct JRE. However, I don't like this approach since it leaves open questions, like how to ship security updates to the JRE.
And by the way: Is Java 6 still supported? To use an old JRE is pretty big security issue.
I'm currently running my web application on Java1.5 codebase, running it on Tomcat 5.5 and MySql 5. Looking through the list of additions that were added into Java1.6, I have to ask the question, "Is there any compelling reason to move from 1.5 to 1.6?". There seems like an incredible lack of necessary improvements and additions. A lot of changes in Swing (not that interesting). Keep in mind the current web application is stable (-ish) and moving up a version always entails some risk.
Am I missing anything important by not moving up? Is there a good reason to move up?
Faster execution time.
Better dynamic debugging.
Better native look and feel in Swing (not important to web apps).
Supported on Windows Vista (could become important, depending on your platform).
JavaScript integrated into the platform (could be a big deal if you update your webapp).
Better scripting language support (could deploy RoR in theory, if needed).
Lightweight web services platform integrated (might be useful).
Better already integrated JDBC4 support.
In other words, it depends, but generally there's enough to make a compelling argument. There's also enough that you might not benefit from to make a compelling counter argument.
Eventually you will have to change. When you do, if you've made the counter argument to stay the same for too long, you wind up having to fix multiple accumulated historical issues all at once. That can overwhelm a team, so sometimes it is best to stay "just a bit behind" current, but never very out-of-date.
I'm assuming you've looked over the features page, and if you haven't, you should.
Java 5 went "end of service life" in 2009.
The newer VM is faster.
Sun (now Oracle) Java 5 has reached end-of-service-life status on October 30, 2009. That means that Oracle will not do bug- and security-fixes anymore on it, unless you pay for a "Java SE for Business" contract (see the web page for details).
Besides that, Java 6 contains a lot of performance improvements (which might or might not matter for your particular application).
It's usually easier to keep an application up to date if you stay on the most recent version.
(Not bleeding edge, but current).
The transition between 1.5 and 1.7 may require more work than if you make the shift to 1.6 first.
jvisualvm in the JDK is reason enough to upgrade. Allows you to investigate and profile an already running process without any preparation.
Is it really viable to use GCJ to publish server-side applications? Webapps?
My boss is convinced that compiling our (my) webapp into a binary executable is a brilliant idea. (Then again, he likes nice, small simple things with blinky lights that he can understand.) He instinctively sees no issues with this, while I only see an endless series of problems and degradations. Once I start talking to him about the complexity of our platform, and more in depth specifics of byte code, JVMs, libraries, differences between operating systems, processor architectures, etc...well...his eyes glaze over, he smiles and he has made it clear he thinks I'm being childishly resistive.
Why does he want a single magic executable? He sees a couple of "benefits":
If it is a binary executable, then it is hard to reverse engineer and circumvent any licensing. Management lives in constant fear that this is happening, even though we sell into larger corporates who generally do not do cheat with server software.
There is that vision of downloading this magic executable, running it, and everything works. (No more sending me out to do customer installations, which is not that frequent.)
So, I've done my obligatory 20 minutes of googling, and now I am here.
A bit of background on my application:
What it is made from:
Java 6 (Sun's JVM)
AspectJ 1.6
Tomcat 6
Hibernate 3
Spring 2
another two dozen supporting jar files
What it does
A streaming media CMS
Performance sensitive
Deployed on Linux, Solaris, Windows (and developed on a Mac)
As you can probably gather, I'm highly skeptical of this "compiling Java to native code" thing. It sound like where Mono (VB on Linux) was back in 2000. But am I being overly pessimistic? Is it viable? Should I actually spend the time (days if not weeks) to try this out?
There is one other similar thread (Java Compiler Options to produce .exe files) but it is a bit too simple, the links dated, and not really geared towards a server-side question.
Your informed opinions will be highly cherished, my dear SOpedians! TIA!
I don't know about GCJ, but my company uses Excelsior JET with success. We haven't done it with a webapp (yet) but it should be able to handle anything that the Sun JRE can. In fact JET is a Sun-certified Java implementation.
FWIW: I have never had good luck with GCJ, I have had a lot of problems using it and have had some obscure issues pop up that took forever to diagnose to GCJ rather than me (I am always very very reluctant to blame things on external libraries). I will openly admit this happened several years ago and I have never wanted to go near GCJ again. To give that more substance this was while I was in school and was working on a mostly trivial program so on an "enterprise level" I have had a healthy fear of GCJ.
Excelsior JET is the definitive answer
Having one executable has a few downsides:
You can't patch it as easy (i.e. replace one class file)
I don't think it can be called a webapp -- I assume it won't run in Tomcat.
It is non-standard so that increases your maintenance costs.
It is non-standard so tool support is reduced.
If he wants something simple maybe a war or ear would be better. I can't see any benefit to doing this -- I would think this might be beneficial it it was a standalone application that you distributed so that people can just double-click on it.
I've only used GCJ very briefly, and quickly moved to Sun's JDK. The main problems I saw was that GCJ seems to always lag a little behind the latest version of Sun's JDK and that there were weird mysterious bugs caused by subtle differences with Sun's JDK. In version 1.5 (which is supposd to be compatible with Sun's v1.5), I had problems compiling using generics, and finally gave up and moved to Sun's JDK.
I must say, any difference in performance was negligible (for my purposes, YMMV) and really the solution for installation issues is to create an installer for your app. Reverse engineering a binary isn't really all that harder than reverse engineering bytecode. Use an obfuscator if it is that important.
Overall, I think the compatibility problems involved in using GCJ greatly outweighs any gains (which I think questionable at best) you might possible derive from it. Try compiling parts of your app in gcj and see how it goes though. If it works out fine, otherwise you get something solid to pitch to your boss.
I'll play devils advocate a bit, though I know little about GCJ.
Compiling to native code may give your application a performance boost and use less memory, so if it can be made to work, there are advantages for the business in terms of competition.
Being able to support an application better is also a good for business.
So perhaps it is worth investigating baring in mind that nothing can lose a customer faster than an application that doesn't work.
You need proper project time to try this out and a customer, that knows what they are getting into, that is willing to give it whirl (harder to find).
I don't think that a large application like yours will compile to machine code. Remember that java is not only java syntax (might compile to machine code) but also a virtual machine which is more like an application / process environment. I would suggest making an uberjar or like that instead.
Perhaps your boss just needs a demo as to how easy it is to distribute and deploy a war file for your customers on their own app servers. Every file is "binary", so you might be too-literal in thinking he means an executable on the command-line.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
When java was young, people were excited about writing applets. They were cool and popular, for a little while. Now, I never see them anymore. Instead we have flash, javascript, and a plethora of other web app-building technologies.
Why don't sites use java applets anymore?
I'm also curious: historically, why do you think this occurred? What could have been done differently to keep Java applets alive?
I think Java applets were overshadowed by Flash and ActionScript (pun unintended), being much easier to use for what Java Applets were being used at the time (animations + stateful applications).
Flash's success in this respect in turn owes to its much smaller file sizes, as well as benefiting from the Sun vs. Microsoft suit that resulted in Microsoft removing the MSJVM from Internet Explorer, at a time of Netscape's demise and IE's heavy dominance.
1) AWT made for horrid UIs. Swing improved on that but it was too late, because...
2) Microsoft dropped support for Java in the browser (its propietary MSJVM), and before it did, it would only support the last version it released, which was roughly JDK 1.1 compatible.
3) So today you cannot be sure that an applet will run on the majority of non-developer machines, unlike flash.
Same can be said of ActiveX by the way.
For what it's worth, Sun is pouring money and resources into applets again. They've made some really significant improvements in JDK 1.6.10 to mitigate a lot of the 'clunkiness' applets used to exhibit. For instance, with this update, you can display your own custom loading image/animation while your applet loads, and the plugin has been put on a major diet to improve performance.
They've also embarked upon an initiative to directly compete with Flash and Silverlight - JavaFX.
Whether or not the market will respond to any of this remains to be seen, but it's certainly a fascinating move on Sun's part given Flash's dominance in the market place.
By the time Java's GUI API stopped totally sucking, everyone was using Flash. And even today, Java is no where near as good as Flash at doing fancy graphics.
I assume it's because java is a "real", ie. general purpose language. To make an applet, you have to write code, and there aren't any shortcuts.
Now that flash etc have come along, you can pretty much just drap and drop your way through making a cool animation for your website. This is a much lower barrier for entry - you don't have to know how to program in order to get a flash animation working. So flash proliferates, and java applets are hardly used anymore.
I think applets are collateral damage in the battle between Microsoft and Sun.
At first, the JVM was very slow to load and demanded too much memory.
Then, when increase in computing power made the JVM possible, Sun played hard as it attempted to control all things Java:
As part of another private antitrust lawsuit filed against Microsoft by Sun in March, Sun sought a preliminary injunction requiring Microsoft to include a current Java virtual machine (JVM) in the Windows XP operating system. Microsoft said the decision to include the JVM this week is a direct result of the latest legal entanglement with Sun, but Microsoft plans to disband support for Java in Windows following Jan. 1, 2004. Microsoft Reverses Course, Will Include Java VM In Windows XP--For Now
They took forever to load up and get going in the browser, and then for a lot of people they didn't work. When they finally did load, the interfaces were ugly and clunky. I think the poor user experience was a big step towards making applets obsolete.
So to answer the original question I have a question of my own - you ask "Why don't sites use java applets anymore", and my response is "why would anyone want to?"
I see them a lot in acedemic settings (hosted on department or faculty sites), but you're right in that they are not very popular.
However, remember that Java's big promise has been achieved. We have Flash, Java Applets, Silverlight, and ever-improving JavaScript frameworks.
Now if I made add a personal opinion - I think that Java applets are inelegant. They tend to look ugly, the Java runtime makes its presence in the OS far too known (in terms of runtime visuals, updates, and the ugly installer). Flash is much better with its rich media environment and its transparent (and ubiquitous) deployment.
People still use applets. But you are right, there are tons of different solutions out there. For example, take a look at javafx
I think compatibility issues were a big problem. Most notably with IE and Microsoft's Java VM which wasn't as standards compliant as it might have been.
Even with the Sun JVM you could have problems. I've had fun where I've had two 3rd-party Applets requiring different versions of Java which causes all sorts of problems. Sun have tried to solve this problem by replacing Applets with Java Web Start which gives you a link in the browser that launches the application in it's own window instead of inside the browser. (In theory with JWS you can have different applications using different VMs but it never seems to work for me as well as it should.)
Advancements with JavaScript have also made it possible to developer much richer web pages so a lot of things in the past that you could only do in Applets can now be done simply with AJAX.
First, they not gone. You can still find lot of applets on the Web, lot of people use them particularly to demonstrate algorithms and such.
Advantages: can leverage existing libraries (math, physics, sorting, graph, etc.) and it is faster than Flash.
Inconvenience: it might be risky to target a recent JVM (although Sun did a good job on automatic updates, looks like lot of people are using Java 1.6 already), load time is a bit slow (even though great progress have been made there).
You can still find lot of game applets too, like Bookworm, with the added advantage, perhaps, to have part of work already done to run them on mobile phones...
Second, I can predict a regain of interest with JavaFX. Applets on steroids, able to break legend of "applets are ugly"... :-)
Last, a library like Processing makes super easy to create graphical intensive applets, and you can find lot of them on the Net, eg. on OpenProcessing where the worst (beginners in programming) is near the best!
I wonder how widespread the JVM actually is? In the case of Flash, IE5 preinstalled it, giving it a large automatic user base. But unless the JVM was included with the OS install, users wouldn't have it. I suppose as a developer you target the largest install base, meaning choosing Flash over Java.
There are Java applets here and there; definitely not widespread though.
i believe it's their ugliness that kept them away from the modern web. flash brought the design, javascript brought a convenient way to make some cool things on a client. being a box inside a browser (just like a flash, though, but much uglier) applet technology was put away.
actually, the only thing that might be missed is the possibility to have a 'client-server' type of communication inside the web, because java applet could have a stateful connection. on the other hand, you would have to put some server on the other side and open a port for it, which just was too much house-work for shared hosting environments.
applets still live in some different areas, like control centers for roads, tunnels, power plants and stuff like that.
People are still using applets, at least for the company that I am working with. The applets are used mainly by internal users.
I feel that applets have their benefits, as companies which employ Java at the server side, most probably will have a large pool of talents who are better skilled at Java.
Although perhaps other technologies like Javascript, HTML/CSS or flash are more popular or more fanciful, but the talent pool could be better employed to create web apps with Java applets as it is a language that they are already familiar with through their work with the server end stuff.
It could be faster for the Java talent pool to deliver a change request with Java applet solutions at a higher accuracy than any other technologies.
Sometimes, the most important thing in a technology solution is its functionality and how fast people who need to provide support for them can react to changes.
The JVM is very widespread, especially in the coorporate world, at least where I've worked, there was always a JVM installed.
I'm currently working on a Java Applet, but in general, I would never an applet unless I had to. But then again, I wouldn't use Flash or Silverlight, either. Applets have a slow load time, and look out of place in webpages. Also, Macromedia/Adobe have outmarketed the good ol' applets.