I have an third-party applet that requires JRE v1.5_12 to work correctly. THe user is installing JRE v1.6.07 or better. It used to be with 1.5 and below, that I could have multiple JRE's on the machine and specify which one to use - but with 1.6 that apepars to be broken. How do I tell the browser I want to use v1.5_12 instead of the latest one installed?
For security reasons, you can no longer force it to use older JRE's. Say release 12 has a huge security hole, and everyone installs release 13 to patch it. Evil java applets could just say "run with release 12 please" and then carry out their exploits, rendering the patches useless.
Most likely you have some code with security holes that the newer JRE is blocking, because it would cause a security risk. Fix your code, should be pretty minor changes, then you wont have to worry.
See this page for more info on the change.
The new applet engine (that will be shipped with 1.6u10 when Sun gets around to officially shipping it) gives you a tremendous amount of control in this area. It's going to take awhile to get enough systems on 6u10 to where you can actually rely on the functionality (unless you are corporate) - but it is coming (seems like it's about 5 years too late).
Here's a JavaWorld article describing this at a very high level: article text
6u10 also has a deployment toolkit that provides super easy to use javascript snippets that you can include in your applet deployment pages. These snippets handle JRE version checking, user notification, JRE downloading on demand, and a number of other things that are otherwise a hassle (not impossible, just a pain). The deployment kit has been designed to fail gracefully, so it does amazing things if 6u10 or above is installed, and drops back to decent behavior for older JREs.
One really, really nice thing about the new applet engine is that it runs in a separate process space from the browser. This has a couple of very big advantages, including the ability to have multiple applets running in different versions of the JRE (yes, you can specify different required JREs, including restrictions on how old and how new of JRE you support - the applet engine will re-use JREs if it can, but it has the ability to start up a different one if it needs).
Related
I have an application in the form of a jar file which is around 2MB in size. For several reasons, I have to bundle the JRE with my application. When I create an MSI with my jar and the JRE, the MSI size comes out to be around 30MB.
I am looking for a commercial or free JRE which I can bundle so that I can reduce the size of my MSI to as low as possible. I am looking at 5MB total, but even upto 10MB may be OK.
Prebuilt JRE Binaries would be great, but not an absolute must.
I looked at similar questions posted here and here.
A lot of answers in these and other threads suggest Excelsior. I downloaded an evaluation version of Excelsior JET & Tried it out - for a few reasons, I think it may not be the right product for me.
1) Excelsior looks at reducing the footprint of the Installed Product not the Installer. I don't care much about the size of the Installed Product - I am mainly looking at a smaller download (the installer of my product currently at 30MB).
2) Amongst other things, Excelsior does lot of optimizations to code to achieve this - I don't want my jar file touched at all. I want a smaller JRE with my jar as is. There isn't a way to turn off some of the optimisations also.
3) Excelsior creates an EXE - I am not particularly looking for this - I am ok with my product being invoked via the javaw.exe command line.
So are there any suggestions for my need?
Avian and ProGuard are your friends as someone has already mentioned in one of the threads you linked to (it's the second comment btw).
From the Avian homepage:
The class library is designed to be as loosely coupled as possible,
allowing tools like ProGuard to aggressively isolate the minimum code
needed for an application. This translates to smaller downloads and
faster startup.
Sounds like exactly what you need. And if that doesn't help you then look at the rest of the tools referenced in that thread.
There is a possible solution here. Those tools install a minimalistic version of Java. I don't know if it is small enough for you. Just take a look and see:
https://superuser.com/questions/745112/how-do-i-run-a-jar-file-without-installing-java
I would make the JRE a separate install from Oracle (or your preferred vendor) You could have it download as required if you wish. If the JRE is already installed, it would be a waste to download it again even a reduced JRE.
BTW: I wouldn't mess with what is in the JRE because
AFAIK its a violation of your license agreement.
Its very difficult to get right and not remove a class you might need one day.
Maybe outdated: there was a rumor about something called JavaKernel/ConsumerJRE.
http://weblogs.java.net/blog/enicholas/archive/2007/05/java_kernel_unm.html
http://www.oracle.com/technetwork/java/javase/kernel-135055.html
We're developing an Eclipse-based RCP. Recently we've updated to Eclipse Juno and currently we focus on quality, which of course brought automated tests into focus, since the application is quite big and the testing effort delays releases.
We're already writing JUnit tests, but I'm more interested in UI tests. With older Eclipses this would not be a problem. There are plenty of good test frameworks around. Unfortunately with Juno everything changed due to the added ability to switch out the default SWT UI by Swing or JavaFX (at least this is what I've understood about the changes causing problems)
So most of the test tools don't work properly anymore. From past experiences it seems that:
SWTBot seems to get not much love lately and is very unstable (can't find elements in certain versions)
Window Tester seems quite good, but has a lot of problems identifying an element during the test run (especially with pop-ups such as content assist or tool tips)
Apparently Froglogics Squish supports Juno, but since a license costs about 2,5k Euro I have to pass
The same seems to be the case for QF-Test (too expensive).
This leaves Jubula (or GUIDancer, which is the commercial Jubula), which we've tried in the past, but which had similar problems as Window Tester and SWTBot (unstable in terms of changes to the Eclipse platform and difficulties to detect some elements)
I need to know, which tool to focus on / trust in. Does anybody have experience with one of the tools or is even currently testing a Juno RCP (or Juno itself for that matter)? Or does anybody know how Eclipse tests their own platform (if they even do it atm)?
Searching for information related to "test", "Juno" and "UI/GUI" only brings up the commercial products.
For me it is important, to find a tool, where I can use the developed test cased even in future releases, which means: A framework project, which has some support of the community to be able to adapt quickly. Also it is important to also find stuff like tool-tips, overlays or content assists/suggestions) - similar to a Selenium compared to basic HTMLUnit.
At this point I don't even care too much about integration, reporting or compliance to standards..
You can find a comprehensive table of GUI-Testing tools in the Eclipse Wiki:
http://wiki.eclipse.org/Automated_Testing#UI_tests
One important decision you have to make is, if you want to use your mouse to record/create tests (Jubula, QFTest, ...), if you want to be able to hand-write test-code (SWTBot, ...), or if you want to be able to do both (WindowTester Pro, ...).
Eclipse Juno is rather new, and I would expect problems with all of the listed tools, however the migration should not take that long since most of these tools mainly focus on testing SWT-widgets and Juno still uses SWT. So far I have not heard from any RCP Application seriously using JavaFX other than for technical demos, but I would be curious to see them!
The problem I think, is rather that testing Eclipse is hard and GUI-testing is especially hard.
You might want to have a look at this study which finds and explains the major problems:
http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2011-010.pdf
If you believe this study, JUnit-testing is usually preferable to GUI-testing. Well, with Juno you have the big advantage that Unit-testing Eclipse now is easier than it ever was because the framework switched from inheritance and singletons to dependency injection, which makes it far more testable.
I'd suggest you too look at Xored's Q7, which is used for GUI testing of some of Eclipse projects including Eclipse DLTK, Eclipse LDT, Eclipse Tigerstripe and the tool is just perfect : it let you develop dozens of UI tests per day per engineer, and do not have stability and incorrect-recording problems. It's designed specially and only to test Eclipse-based apps and obviously the best in the niche.
However it costs money, which can be a blocker for you (like squish), but they have a free Community version, which is enough for most of use-cases. As well as those Xored guys just introduced pay-per-testexecution pricing model -- the tools will be free and you have to pay as you go only per tests executed monthly (less than 5000 is free). More about new model is here eclipse-testing.com
I have minimal exposure to RPM, Windows installer mechanics, and WIX. That said, I'm interested in making a cross-platform installer tool (Linux, Windows) that supports upgrading and downgrading (versiona and patches) of my own product. I don't believe this is a topic to be approached lightly; I would like to learn the science of the art (or the art of the science). If I succeed, and build a minimally successful installer tool, it would have these features:
does not depend on a platform-specific tool (such as Windows Installer).
reads XML or a declarative syntax to fulfill installation requirements.
attempts to minimize steps to upgrade or downgrade one of my products (rather than requiring a complete uninstall and re-install).
does not require knowledge of interim product versions, in order to jump versions (i.e. can upgrade one of my products from version 1 to version 3, without passing through version 2).
I'm convinced that "the key" to achieving this goal is by seeing versions as a "point A to point B" problem, which implies that A and B are described by two XML "version" documents that hold info about all the parts and actions (files, or platform specifics such as registry entries). My installer tool would "join" or compare the two documents and determine a minimal set of changes to transform A into B. To some extent, I believe this is precisely what Windows Installer does.
Of course there are further complexities, but that is the point of this post. Where is "the bible" of information on this topic? Remember, I want to make my own installer - not use a platform-specific one. For those who care, my products are usually written in C++ or C#.
Or perhaps I should study something like Steam which is cross-platform and has "automated game updates" as part of its capabilities. In my case, the problem of online deployment is already handled. It is just the final installation step I'm examining. Does Steam use native installers (such as an MSI)? If yes, then that is not what I'm looking for.
In short, what path should I pursue to become somewhat competent on the science of this topic?
I'm not an expert and others can give you better answers but...
Don't declaratively list steps required to install your product - You'll end up making assumptions which will eventually prove wrong. Instead, you should be looking at defining the final state of the installation and let the installer worry about how to make that happen.
Another consideration is that being downgradable may involve huge complications depending on your product - Would it have to down-grade database schemas / file formats / ??? In short, every version of your app will need to be both fully forwards- and backwards-compatible (or at least fail gracefully). Also consider the scenario where V1 of your app stores settings in a file. V2 comes along and adds more settings. You downgrade to V1 - What should it do when changing settings? preserve the V2 settings? dump them? Do some of the V2 settings change the impact/meaning of the V1 settings? Are these decisions to be made by your app or your installer?
Anyway, all that aside, I'd say you need at the least:
A central server/farm with complete files for every version of your App and some API/Web Service which allows the installer to retrieve files/filesets/??? as appropriate (You may be able to tie this into a source control system like svn)
Some way of specifying the desired post-install state of the system in an environment-agnostic way (Think install paths - /usr/??? - should the map to C:\Users\??? or C:\Program Files on windows? Also don't forget it might be a 64-bit machine so it could be C:\Program Files (x86).
A very clever installer written for multiple platforms with as much code re-use as possible (Java, Mono, ???)
The installer should do (simply):
Determine the desired version of the product.
Download/read the appropriate manifest.
Compare the desired situation with the current situation (NB: What is currently on the local system, NOT what should be on the system according to the current version's manifest)
Generate a list of steps to reconcile the two, taking into account any dependencies (can't set file permissions before you copy the file). You can make use of checksums/hashing/similar to compare existing files with desired files - thus only downloading the files actually required.
Possibly take complete backups
Download/unpack required files.
Download/unpack 3rd party dependencies - Later .Net Framework Version/Similar
Perform install steps in atomic a manner as possible (at the very least keeping a record of steps taken so they can be undone)
Potentially apply any version-jump specific changes (up/down-grade db, config files, etc.)
verify installation as much as possible (checksums again)
None of this addresses the question of what to do when the installer itself needs upgrading.
A technique I've used on Windows is that the installer executable itself is little more than a wrapper with some interfaces which loads the actual installer dynamically at runtime - thus I can move files about/unload/reload assemblies, etc... from within a fixed process that almost never changes.
As I said above, I am definitely not an expert, just a novice who's done some of this myself. I sure you can get more complete answers from others but I hope this helped a little
I want to use Selection Service feature from the eclipse RCP in my swing project. Currently the o.e.ui.workbench bundle which contains the related interface is around 3.7 MB, that's way too huge for our requirement
Is there any way to split it the workbench to get only the selection service
Are there distros already for this
Is it leagal to do so. Are there any licencse issues?
It does not look like it would be that hard to do it yourself, and that's pretty much what you would have to do. I know of no distros that do this however.
It's certainly legal to do so; you can freely use or modify any part of Eclipse until the EPL. If you split it without modifications then you have no obligations under the license. However if you extend it (and redistribute your code), then you need to make available your code that extends it (which can be done using an Eclipse bug report for example).
What is the best version control system to implement with PowerBuilder 11.5?
If you have examples of how you have did branching/trunk/tags that would be awesome. We have tried to wrap our heads around it a few times and always run into problems because we use shared libraries such as PFC/PFE in multiple applications.
Right now we are only using PBNative, and it sucks.
The Agent SVN is a MS-SCCI Subversion plug-in works with PowerBuilder.
Here is a link that describes how to setup Agent SVN to work with PowerBuilder and Subversion.
We currently use Perforce and it's P4SCC plugin, which works very well. In fact, I'm sure I read somewhere that the guys at Sybase who write PowerBuilder, actually use Perforce themselves.
So, to be fair, let's start out by saying that while you're asking about version control, PBNative is source control. If you compare something that is intended to have more features than just keep two developers from editing the same piece of source, then yes, PBNative will suck. The Madone SL may be an incredible bicycle, but if you're trying to take a couple of laps around an Indy track, it will suck.
"Best" is a pretty subjective word. There are lots of features available in version control and configuration management tools. You can get tons of features, but you'll pay through the nose. StarTeam has some nice features like being able to trace a client change request or bug report all the way through to the changed code, and being able to link in a customized diff tool (which is particularly useful in PB). Then again, if cost is your key criteria rather than features, there are lots of free options that will get the job done. As long as the tool supports the Microsoft SCC interface, you should be OK.
There is a relatively active NNTP newsgroup that focuses on source control with PowerBuilder, which you can also access via the web. You can probably find some already-posted opinions there.
Many years ago I used Starteam to control PB applications. PowerBuilder needless to say is an outdated bear, and it has to export each and every object from its "libraries" into source control.
Currently our legacy PB apps have its libraries saved whole into Subversion, without any support for diff's etc.
We use Visual SourceSafe. We don't use PFC, but we do have libraries that are shared among several projects. Till now, each project was developed separately from the others, and so the shared libraries were duplicated. To have them synchronized, they were all shared at the VSS level. Lately we've reorganized our sources so all projects are near each other, and there's only one instance of the shared libraries.
VSS is definitively not the best source control system, to say the least, but it integrates into PB without the need of any bridges. PB has an inherent problem working with source control, so it probably won't make a very difference working with one instead of the other (at least from the PB point of view).
Now, on a personal note, I'd like to say PB 11.5 is a piece of sh*t. It constantly crashes, full of unbelievable UI nuisance and just brings productivity to its knees. It's probably the worst IDE ever created. Stay away if possible.
FYI: The new PB12 (PB.NET) will integrate with SCC systems so you can easily choose which source control system that you want to use. Since we basically have dropped PBLs (they are now directories) files can be checked in/out individually - even with a plain vanilla editor since files are now normal (unicode) text files.
StarTeam integrates so beautifully with the PB IDE. I used that combination at my previous company (PB9 and ST5.x) for several years. You should be managing your code at the object level - don't log the entire PBL into ST...
If you're having problems with that setup, hit me up offline. phoran at sybase dot com.
We use Merant Version Manager for older projects and TFS for newer work. The only issue we have is that TFS does not support keyword expansion and changing the 'read the flowerbox comments' attitude people have. Some folks are nervous about losing the inline versioning history.
We use StarTeam and have been very pleased with it. It combines bug tracking with version control. Unfortunately though we don't store our files on the object level. We just store the PBL files directly in source control. Anything that supports the SCC interface theoretically should work correctly in PowerBuilder.
PB9: We used PVCS but had stability problems with pbl corruption and also problems co-existing with later versions of Crystal Reports (dll conflict) so now we use PB9 with Dynamsoft's Source Anywhere Standalone. This system is more primitive; it is missing the more advanced features for promotion levels and for pulling out an older milestone version of all objects to make a patch build.
What we are looking for now is something which will allow more advanced "change management", to support promotion levels at the change level (rather than at the object level). Would it be better to use perforce, starteam, or (harvest change manager + HarPB), or something else? Any advice on these combinations would be greatly appreciated.
You can always use Plastic SCM with PowerBuilder through SCC. Plastic is pretty advanced in terms of graphics, tools, replica and so on, so it's always a good choice to keep in mind.