Thursday, June 25, 2020

Eclipse JustJ

I've recently completed the initial support for provisioning the new Eclipse JustJ project, complete with a logo for it.

I've learned several new technologies and honed existing technology skills to make this happen. For example, I've previously used Inkscape to create nicer images for Oomph; a *.png with alpha is much better than a *.gif with a transparent pixel, particularly with the vogue, dark-theme fashion trend, which for old people like me feels more like the old days of CRT monitors than something modern, but hey, to each their own. In any case, a *.svg is cool, definitely looks great at every resolution, and can easily be rendered to a *.png.

By the way, did you know that artwork derivative of  Eclipse artwork requires special approval? Previously the Eclipse Board of Directors had to review and approve such logos, but now our beloved, supreme leader, Mike Milinkovich, is empowered to do that personally.

Getting to the point where we can redistribute JREs at Eclipse has been a long and winding road.  This of course required Board approval and your elected Committer Representatives helped push that to fruition last year.  Speaking of which, now there is an exciting late-breaking development: the move of AdoptOpenJDK to Eclipse Adoptium.  This will be an important source JREs for JustJ!

One of the primary goals of JustJ is to provide JREs via p2 update sites such that a product build can easily incorporate a JRE into the product. With that in place, the product runs out-of-the-box regardless of the JRE installed on the end-user's computer, which is particularly useful for products that are not Java-centric where the end-user doesn't care about the fact that Eclipse is implemented using Java.  This will also enable the Eclipse Installer to run out-of-the-box and will enable the installer to create an installation that, at the user's discretion, uses a JRE provided by Eclipse. In all cases, this includes the ability to update the installation's embedded JRE as new ones are released.

The first stage is to build a JRE from a JDK using jlink.  This must run natively on the JDK's actual supported operating system and hardware architecture.  Of course we want to automate this step, and all the steps involved in producing a p2 repository populated with JREs.  This is where I had to learn about Jenkins pipeline scripts.  I'm particularly grateful to Mikaël Barbero for helping me get started with a simple example.  Now I am a pipeline junkie, and of course I had to learn Groovy as well.

In the initial stage, we generate the JREs themselves, and that involves using shell scripts effectively.  I'm not a big fan of shell scripts, but they're a necessary evil.  I authored a single script that produces JREs on all the supported operating systems; one that I can run locally on Windows and on my two virtual boxes as well. The pipeline itself needs to run certain stages on specific agents such that their steps are performed on the appropriate operating system and hardware.  I'm grate to Robert Hilbrich of DLR for supporting JustJ's builds with their organization's resource packs!  He's also been kind enough to be one of our first test guinea pigs building a product with a JustJ JRE.  The initial stage produces a set of JREs.

In the next stage, JREs need to be wrapped into plugins and features to produce a p2 repository via a Maven/Tycho build.  This is a huge amount of boiler plate scaffolding that is error-prone to author and challenging to maintain, especially when providing multiple JRE flavors.  So of course we want to automate the generation of this scaffolding as well.  Naturally if we're going to generate something, we need a model to capture the boiled-down essence of what needs to be generated.  So I whipped together an EMF model and used JET templates to sketch out the scaffolding. With the super cool JET Editor, these are really easy to author and maintain.  This stage is described in the documentation and produces a p2 update site.  The sites are automatically maintained and the index pages are automatically generated.

To author nice documentation I had to learn PHP much better.  It's really quite cool and very powerful, particularly for producing pages with dynamic content.  For example, I used it to implement more flexible browsing support of so that one can really see all the files present, even when there is an index.html or index.php in the folder.  In any case, there is now lots of documentation for JustJ to describe everything in detail, and it was authored with the help of PHP scaffolding.

Last but not least, there is an Oomph setup to automate the provisioning of a full development environment along with a tutorial to describe in detail everything in that workspace.  There's no excuse not to contribute.  While authoring this tutorial, I found that creating nice, appropriately-clipped screen captures is super annoying and very time consuming, so I dropped a little goodie into Oomph to make that easier.   You might want to try it. Just add "-Dorg.eclipse.oomph.ui.screenshot=<some-folder-location>" to your eclipse.ini to enable it.  Then, if you hit Ctrl twice quickly, screen captures will be produced immediately based on where your application currently has focus.  If you hit Shift twice quickly, screen captures will be produced after a short delay.  This allows you to bring up a menu from the menu bar, from a toolbar button, or a context menu, and capture that menu.  In all cases, the captures include the "simulated" mouse cursor and starts with the "focus", expanding outward to the full enclosing window.

The bottom line, JustJ generates everything given just a set of URLs to JDKs as input, and it maintains everything automatically.  It even provides an example of how to build a product with an embedded JRE to get you started quickly.  And thanks to some test guinea pigs, we know it really works as advertised.

On the personal front, during this time period, I finished my move to Switzerland.  Getting up early here is a feast for the eyes! The movers were scurrying around my apartment the same days as the 2020-06 release, which was also the same day as one of the Eclipse Board meetings.  That was a little too much to juggle at once!

At this point, I can make anything work and I can make anything that already works work even better. Need help with something?  I'm easy to find...


del65 said...

I struggled to embed a JRE into a p2 repository with Tycho for an Eclipse RCP product.

Thankfully I found some help with the p2 documentation to bundle the JRE into a feature ( following the advice from, and used touch points to alter the eclipse.ini file to point to the appropriate target VM when installing/uninstalling the feature (which is set to allow only one installed feature at a time).

But... on Windows dropping an unused feature or plugin may require a restart of the whole operating system to remove currently accessed files.
As a result disabling a feature is better than removing it, but p2 can only uninstall (which implies deletion of) a feature ( discussion : ).

It is also better to keep some sort of fallback in case of failure of the startup following the install of the new JVM. Restart failures can come from old JVM options in eclipse.ini which become incompatible with the new JVM, or a plugin which doesn't start anymore with the new JVM (because it relies on the presence of a jigsaw module which is not available anymore).

Does the JustJ proposal include a solution for those drawbacks ?

Ed Merks said...

In general, p2 only does the deletion after a restart of the application, i.e., it's really just an automatic garbage collection phase shortly after a restart. Also, the Eclipse Installer uses a shared bundle pool by default, and the shared pool is only garbage collected manually by the user. So nothing is ever deleted automatically in that case.

Also note these bugs have been fixed:

In any case, I would expect if the restart fails, no garbage collection would be done, so the older feature/plugin containing the JRE would not be deleted yet.

In addition, the JustJ installable units specify the actual package capabilities of the JRE, so if bundles at least use package imports, missing packages would cause a resolution failure rather than a subsequent runtime (wiring) failure. But of course most plug-ins don't specify package imports for JRE-provided packages...

There are no special solutions being proposed, i.e., nothing that would require additional implementation support in p2 itself. The JustJ JREs just use what p2 already provides.

wimjongman said...

Thanks, Ed, really nice. It comes at just the right time for us. Also, JET.. It has been generating our database classes since 2008. A joy to work with.

梁爵 said...

2020.08.09不敢來酒店上班-酒店打工的原因我很慶我幸身為一個女人。也很慶幸我是一個打扮起來還不差的女人。十八歲生日沒有狂歡沒有慶祝。酒店小姐的基本介紹跟工作內容在網路上找了間經紀公司,當天下午就開始上班。我在酒店上班的日子年輕的肉體再加上尚未染上風塵的氣質,很快我成了店裡的紅牌。下午茶玩的是什麼? 酒店兼差不是一個複雜的工作環境?酒店晚上營業,下午時段店家場地借給午茶,就是在那樣的小包廂裡,一個客人一個小姐,大約五十分鐘的時間,就看小姐怎麼讓客人在這短短的時間小小的包廂裡喜歡上自己。酒店小姐上班通常會取什麼名字?有客人喜歡,才會有指台,酒店小姐去酒店上班都一定要出場接s嗎?才會有預約。中午十二點上班,晚上八、九點下班,換了衣服卸了妝,身邊沒有人發現我的工作特殊。一樣的一天八小時,每上一台我可以領個一千。或許吧!有的人覺得我出賣身體、出賣靈魂。但是我寧可出賣這些,也不想過像我的父母那樣的生活,那樣捉襟見肘的生活,那樣跟西家借錢還東家的生活,那樣無止盡為錢爭吵的生活,那樣要躲在家裡不出聲不開燈以免被發現的生活,那樣連感冒想去藥局買個成藥都要惦量惦量的生活。還記得工作第一個禮拜,我領了兩萬多的薪水。那些扣除林林總總後居然還有這樣多!這是我第一次拿著那麼多錢,我好想大聲地告訴我的父母,我會賺錢了,若是時光回溯,我是不是就可以幫上你們的忙了?大約過了兩三個月,一開始覺得「領好多錢」的感覺也沖淡了。開始審視自己要的是什麼?我想要有一個家,一個完完全全屬於我的家,一個不用因為繳不出房租被房東趕的家。於是我不再是那個滿足於一個禮拜領個三萬左右的女孩。