Jira is feature-rich and exceptionally flexible, bending to meet your needs. Here are the add-ons and integrations to improve your software delivery processes.

this article is part 2 of a tutorial that will walk through adapting an open source javafx radialmenu ( http://jfxtras.org/ ) to replace the netbeans platform system menu. it will build upon both previous tutorials and part 1 that demonstrate complete replacements for the default netbeans swing components using javafx. code examples will feature netbeans platform, javafx and css. part 1 of the article walks through some of the code upgrades necessary for the task. as of this article’s writing the open-source jfxtras radialmenu needed a few upgrades to act as a system menu replacement for a netbeans platform rcp. part 2 will show the specific algorithm and code to then utilize the upgraded radialmenu as described. when complete you should be able to produce a slick radial system menu like this: previous tutorials in the integrating javafx with the netbeans platform series we showed how to replace the netbeans swing menubar with javafx components. you can find these tutorials here (first link is part 1): https://dzone.com/articles/javafx-accordion-slide-out https://dzone.com/articles/tabs-tabuless-netbeans and they are extensions themselves of these great articles written by geertjan wielenga: https://dzone.com/articles/how-integrate-javafx-netbeans-part2 to fully understand and follow this tutorial you will need to start with the previous tutorials mentioned above, especially part 1. create recursive container building method like most of the previous menu replacement articles, we are going to use recursion to build our components. in this situation we want to recursively build our extended radialcontainermenuitemsp components that we upgraded in part 1 of this tutorial. add this recursive method to your jfxradial component class: private void buildradialcontainermenuitem(fileobject fo, final radialcontainermenuitemsp rcmi) { datafolder df = datafolder.findfolder(fo); dataobject[] childs = df.getchildren(); for (dataobject onechild : childs) { //create filler graphic for container imageview filler = imageviewbuilder .create() .image(new image("jfxradial/dark_compass_icon_16.png")).build(); if(fo.getname().equals("web browser")) { system.out.println(); } //if child is folder we need to build recursively if (onechild.getprimaryfile().isfolder()) { fileobject childfo = onechild.getprimaryfile(); //create radialmenucontaineritemsp final radialcontainermenuitemsp newcontaineritem = new radialcontainermenuitemsp(containersize, childfo.getname(), filler, false); //recursively build submenu buildradialcontainermenuitem(childfo, newcontaineritem); //add radialmenucontaineritem to radialmenu rcmi.addmenuitem(newcontaineritem); } else { object instanceobj = fileutil.getconfigobject(onechild.getprimaryfile().getpath(), object.class); if (instanceobj instanceof action) { //if it is an action we have reached an endpoint final action a = (action) instanceobj; string name = (string) a.getvalue(action.name); string cutampersand = actions.cutampersand(name); //create radialmenuitemsp final menueventhandler meh = new menueventhandler(a); //add action to radialmenuitemsp and hide graphic filler final radialmenuitemsp menuitem = new radialmenuitemsp(menusize, cutampersand, filler, false, meh); //add radialmenuitemsp to radialcontainermenuitem rcmi.addmenuitem(menuitem); } } } } the recursion process of course looks very similar to that found in our previous articles. one thing to note here that the way that because the radialcontainermenuitem class extends the radialmenuitem class and because of the logic we added to dynamically provide mouseclicked event handling, we can recursively build a radialcontainermenuitemsp with as many nested levels as the jdk has memory. then only the root node in the chain needs to be added to the radialmenu itself. feed the netbeans platform system folders into the recursion add this block of code to the end of your createradialmenu() method: fileobject menufolder = fileutil.getconfigfile("menu"); fileobject[] menukids = menufolder.getchildren(); //for each menu folder need to create either radialmenuitemsp or a radialmenucontaineritem to hold sub menus for (fileobject menukid : fileutil.getorder(arrays.aslist(menukids), true)) { try { datafolder.findfolder(menukid); //create filler graphic for container imageview filler = imageviewbuilder .create() .image(new image("jfxradial/dark_compass_icon_16.png")).build(); //create radialmenucontaineritem and recurse //extend a custom container that uses text labels like we did for radialmenuitemsp radialcontainermenuitemsp newcontaineritem = new radialcontainermenuitemsp(containersize, menukid.getname(), filler, false); buildradialcontainermenuitem(menukid, newcontaineritem); //add radialmenucontaineritem to radialmenu radialmenu.addmenuitem(newcontaineritem); } catch (exception ex) { //we couldn’t load so drop it on the floor } } again it looks very similar to all our previous examples. one small note here, i don’t want to actually show any graphics in my menus, only menu text labels. so the filler imageview object is just that… an invisible filler to satisfy the available constructors. adding this code should provide you with a view similar to this: this view of course is after i’ve started clicking around expanding layers. wow. that’s a lot of options. it makes you appreciate how efficient a traditional menu is in terms of space. so right here we’ve already encountered a problem that plagues radial menu’s in general… they take up a ton of space and block out whats behind them. but javafx to the rescue… lets reduce the opacity of the menu to a really low number like 0.1. you can do this by changing the fourth component of the “slightlytrans" color object defined at the top of the createradialmenu() method and recompile. let’s try it with something in the background like a javafx web browsing component: hmmm… a lot of those menu items are too transparent and they don’t show well over dark patterns and backgrounds. let’s up the opacity to 0.3… so we’re getting closer… not bad at all on a light background and a bit better on dark/mixed backgrounds. we should probably increase the opacity a bit more to 0.6. let’s try it on a deeply dark background like a worldwind application! ugh. that grey box represents the specified scene size inside the transparent jfxpanel component. this is a bug when trying to overlay transparent javafx scenery on native/heavyweight components. basically the z-ordering gets mucked up. the non-transparent nodes in the javafx scene are rendered properly but everything else not so much. if someone out there has a workaround please let me and everyone else know. so from now on we will all agree to keep our heavyweight and translucent javafx separate and our opacity around half for all to see. if you follow those rules and these articles you should be able to make lot’s of cool looking menus and interfaces like the one at the start of this article and the one below:

Check out one of the more exciting features from JDK 13 — text blocks!

Continue learning about managing Jenkins configuration as code in this tutorial on migration to JCasC from your current Jenkins master node.

Learn how to manage Jenkins master configuration with simple, declarative YAML files with Jenkins Configuration as Code.

JDK 14 Early Access Build #23 is now available.

You can put JDev files on NetBeans for brand-new creations.

To virtualize and make use of your data, you need to bring it into your platform. See how to do this with JBoss and OpenShift so you can get your data when you need it.

This JavaScript quiz will test your knowledge of arrays along with the order of operations. If you don't know the answer, you'll want to brush up on Array.prototype.map.

This week's JavaScript quiz will test your knowledge of block scopes. We're moving out of the basics and into more advanced topics.

Learn how to avoid common mistakes when working with JavaScript promises. We promise it'll make you a better coder!

[editor's note: be sure to check out part 1 , part 2 , part 3 , and part 4 ] in the fifth part of this javascript kinetic scrolling tutorial, a demo of the attractive cover flow effect (commonly found in some apple products) using the deadly combination of kinetic scrolling and css 3-d will be shown. the entire logic is implemented in ~200 lines of javascript code. the cool factor of cover flow is in its fluid animation of the covers in the 3-d space. if you haven’t seen it before, you miss a lot! to get the feeling of the effect, use your browser (preferably on a smartphone or a tablet) to visit ariya.github.io/kinetic/5 . swipe left and right to scroll through the cover images of some audiobooks. my first encounter to this cover flow effect was 6 years ago as i implemented this with pure software in c/c++. it ran quite well even on a lowly hardware (such as this 200 mhz htc touch ). of course, with gpu-accelerated css animation, there is no need to write an optimized special renderer for this. for this example, we manipulate the transformation matrix directly using css transform feature. to follow along, check the main code in coverflow.js . there are several key elements in this demo. first, we will need a smooth scrolling with the right acceleration and deceleration using the exponential decay technique which was covered in part 2 . also, stopping the scrolling at the right position is necessary ( part 3 , see the snap-to-grid code) as we need to have all the cover images in the perfect arrangement, not halfway and not being stuck somewhere. when you look at the code, the scrolling via mouse or touch events impacts the value of the variable offset . in fact, the code for doing that is line-by-line equivalent to what has been covered in the previous parts. on a normal circumstances, this offset is always an integer multiply of 200 (the cover image size, in pixels). when the user makes a touch gesture to drag the cover or when it is decelerating by itself, then the value could be anything. this is where we need to apply tweening to give the right transformation matrix for each cover image. such a decoupling results in a modular implementation. all the events (touch, mouse, keyboard, timer) only deal with the change in offset, it has no knowledge as to how the value will be useful. the main renderer, which is the scroll() function, knows nothing on how that offset value is computed. its responsibility is very limited: given the offset, compute the right matrix for every single cover. this is carried out by going a loop through the stack of the covers, from the front-most image to the ones in the far background, as illustrated in this diagram. note how the loop also serves to set the proper z-index so that the center image becomes the front cover and so on. every image is initially centered on the screen. after that, the right translation is in the x axis is computed based on the relative position of the image. for a depth perception, there will be an additional translation in the z axis , making the cover going farther from the screen. finally the image is rotated (in the y axis ) with a positive angle and a negative angle for the left and right side, respectively. the 3-d visual comes from the perspective of the main div element which is the parent of every single image element. the entire scroll() is about 40 lines. if the explanation above is still confusing, it is always fun to step through the code and watch the variables as it goes through one cover to another. the code is not crazily optimized, it is deliberately chosen to be as clear as possible without revealing too much. having said that, with the most recent ios or android phones, the effect should be pretty smooth and there is not any problem achieving over 30 fps most of the time. you will get some minor extra frames (particularly useful for older devices) if the reflection effect is removed. since this demo is intended to be educational, i left a few exercises for the brave readers. for example, the tweening causes only one cover to move at a time. if you are up for a challenge, see if you can move two covers, one that is going to the front and one that is going to the back. in addition, the perspective here is rather a cheat since it applies on the parent dom element (as you can witness, these transformed images have the same vanishing point). applying an individual perspective and y-rotation requires wrapping every img element with its container. of course, the 3-d effect does not have to be like cover flow as you could always tweak the matrix logic so that it resembles e.g. montagejs popcorn instead. once you leave the flatland, there is no turning back!

It’s official! We’re getting a new function syntax! The TC39 group (the panel charged with delivering ES 6) has reached a consensus on an abbreviated syntax for JavaScript function expressions. It's popularly known as the fat arrow syntax, and is based on a similar construct found in CoffeeScript. Make no mistake, I’m delighted that we will finally have an alternative to the unnecessary clunkiness and verbosity of the present grammar, but I can’t shake a nagging feeling that this proposal (in its current form) is flawed to the extent that it might actually make new developers more confused than they already were. I’ll run through the key features of this new construct, then explain my concerns and how they might be mitigated. There are Finally Fat Arrows in Java Java continues to add new features and make itself more useful to the public in due course. That said, there are many who have complained that the service never allowed them to put in the fat arrows that they wanted to. It was a glaring hole in the program, and it has now been clamped down on. People are finally able to get the fat arrow designs that they have been looking for without having to use another program to make it happen. Make sure you take a look at the full scope of what Java has to offer you as you explore the promise that it will be something even grander than anything else out on the marketplace at this time. You will want to take advantage of these new arrow designs if you can, and you will want to check up on all of the latest offerings from Java whenever possible. BS Alert Before starting out I should let you know that I’m going to make a lot of assertions about how fat arrows work. I’m reasonably confident that most of them are consistent with the latest proposal, but since research material is scant (I’m relying on the ES Wiki and the ES discuss list) and the examples are not testable (the traceur compiler does not yet support fat arrows) there are going to be some mistakes, for which I apologize upfront. I welcome corrections and will update the content as I get them. Thanks! How does it Work? The Syntax The fat arrow grammar has the following characteristics: 1. The arrow (=>) takes the place of the function keyword 2. Parameters are specified before the arrow, parentheses are required when there are zero, two or more parameters. 3. Block syntax (i.e. enclosing the function body in curly braces) is optional when the body comprises a single expression, otherwise it is required. 4. The return keyword is implied when the function body comprises a single expression. In all other cases returns must be used explicitly. Here are some simple examples. I’ve paired each fat arrow use case with the corresponding long-form syntax, although as we’ll see later the paired functions do not necessarily represent identical behavior. I’m defining variables with the var keyword for the sake of familiarity, but by the time ES6 is implemented you’re more likely to use let which allows variables to be defined with block scoping: //empty function var fat1 = () => {}; var long1 = function() {}; //return the square var fat2 = x => x * x; var long2 = function(x) {return x * x}; //add two numbers var fat3 = (a, b) => a + b; var long3 = function(a, b) {return a + b}; //return square root if x is a number, otherwise return x var fat4 = x => (typeof x == "number") ? Math.sqrt(x) : x; var long4 = function(x) { return (typeof x == "number") ? Math.sqrt(x) : x; }; Fat arrows bring a terse elegance to functional JavaScript… //return a new array containing the squares of the original... [1, 2, 3, 4, 5].map(x => x * x); //[1, 4, 9, 16, 25] //capitalize... ['caption', 'select', 'cite', 'article'].map(word => word.toUpperCase()); //['CAPTION', 'SELECT', 'CITE', 'ARTICLE'] //rewrite all instances of Fahrenheit as Celsius... function f2c(x) { var test = /(\d+(\.\d*)?)F\b/g; return x.replace(test, (str, val) => (val-32)*5/9 + "C"); } f2c("Store between 50F and 77F"); //"Store between 10C and 25C" (The last example is a rewrite of this traditional implementation). No Extras For You, Fat Arrow Not only do fat arrows use lightweight syntax – they also generate lightweight functions… No Constructors Functions created using fat arrow syntax have no prototype property, which means they can’t be used as constructors. If you try to use a fat arrow function as a constructor it throws a TypeError. No Arguments The argument’s object is not available within the execution context of a fat arrow function. This is not a huge loss; by the time ES 6 is in full swing, we can expect arguments to have been deprecated in favor of the rest (...) syntax. No Names There are Function Expressions, and then there are Named Function Expressions. Fat arrow functions have no place for a name, so they will always just be plain anonymous Function Expressions. The Value of This Functions defined with the fat arrow syntax have their context lexically bound; i.e. this value is set to the value of the enclosing scope (the outer function where present, otherwise the global object). //with long-form inner function var myObj = { longOuter: function() { console.log(this); //this is myObj var longInner = function() { console.log(this); //this is global object }; longInner(); } } myObj.longOuter(); //with fat arrow inner function var myObj = { longOuter: function() { console.log(this); //this is myObj var fatInner = () => console.log(this); //this is myObj fatInner(); } } myObj.longOuter(); It's a hard binding, which means if a fat arrow is used to define a method in an object literal it will continue to be bound to that object even when invoked from a borrowing object: var myObj = { myMethod: function() {return () => this;}, toString: () => "myObj" } var yourThievingObject = { hoard: myObj.myMethod, toString: () => "yourThievingObject" }; yourThievingObject.hoard(); //"myObj" Similarly the this value of a fat arrow function cannot be modified by means of call or apply: //traditional long inner function var myObj = { longOuter: function() { console.log(this); //this is myObj var longInner = function() { console.log(this); //this is now myOtherObj } longInner.call(myOtherObj); } } myOtherObj = {}; myObj.longOuter(); //new fat inner function var myObj = { longOuter: function() { console.log(this); //this is myObj var fatInner = () => console.log(this); //this is still myObj fatInner.call(myOtherObj); } } myOtherObj = {}; myObj.longOuter(); So What’s the Problem? If you trawl the JavaScript section of Stack Overflow, you’ll find dozens of questions from puzzled developers trying to get their heads around JavaScript’s somewhat byzantine process of this assignment. So…remember how there are five ways to define the value of this in a function?… Syntax of function call Value of this 1. Method call: myObject.foo(); myObject 2. Baseless function call: foo(); global object (e.g. window) (undefined in strict mode) 3. Using call: foo.call(context, myArg); context 4. Using apply: foo.apply(context, [myArgs]); context 5. Constructor with new: var newFoo = new Foo(); the new instance (e.g. newFoo) …well now there’s a sixth… Syntax of function call Value of this 6. Fat Arrow: (x => x*x)(); this of lexical parent (A seventh rule was also proposed – naming the first argument of a fat arrow as ‘this’ would have bound the context to the base reference of a method call – but thankfully that option has been deferred). I appreciate the rationale behind lexical this binding. It’s intuitive, and if JavaScript was starting over, this would not be a bad way to do it. But at this point I’ve fallen in love with dynamic this values; they make functions gloriously flexible and are a great compliment to functional patterns, wherein functions form the bedrock of data, and other objects are mere fungibles. Moreover, if new developers are already discouraged by JavaScript’s perceived arbitrary assignment of context, yet another rule might be enough to finish them off for good. Bear in mind that fat arrow is sugar, and a very tasty sugar at that; it will be eagerly devoured by many developers long before the consequences of the sixth law of this has time to sink in. There’s another, related issue with the current proposal. Legacy functions (third party or otherwise) generally assume that their function arguments have dynamic this values. This enables them to invoke function arguments in any given context, which, amongst other things, is a useful way to add mixins. It’s true that Function.prototype.bind already offers a form of hard binding, but it does so explicitly; on the other hand, fat arrow’s hard binding is a side effect and it’s not at all obvious that it would break code like this: function mixin(obj, fn) { fn.call(obj); } //long form function mixin is dynamically bound var withCircleUtilsLong = function() { this.area = function() {return this.radius * this.radius * Math.PI}; this.diameter = function() {return this.radius + this.radius}; } //fat arrow function mixin is lexically bound (to global object in this case) var withCircleUtilsFat = () => { this.area = function() {return this.radius * this.radius * Math.PI}; this.diameter = function() {return this.radius + this.radius}; } var CircularThing = function(r) {this.radius = r}; //utils get added to CircularThing.prototype mixin(CircularThing.prototype, withCircleUtilsLong); (new CircularThing(1)).area(); //3.14 //utils get added to global object mixin(CircularThing.prototype, withCircleUtilsFat); (new CircularThing(1)).area(); //area is undefined How to Fix It OK, enough whining; time to make some proposals. Here are three ideas to remove, or at least mitigate, any negative effects of the new fat arrow context behavior. 1) (This one’s easy). Have fat arrow functions define this the same way as any regular Function Expression does – i.e. according to the five rules in the table above. It’s worth noting that CoffeeScript defined fat arrow as an alternative to their thin arrow (->) syntax. Thin arrow in CoffeeScript behaves, by and large, the same way as regular JavaScript Function Expressions. In contrast, ES6′s fat arrow is attempting to do at least two things at once – be the sole abbreviator of the syntax and redefine context assignment. To do one, or the other, would be less confusing. 2) (You probably saw this one coming too). Introduce thin arrow syntax at the same time. That way developers are drawn to the safer, less radical sugar which simply abbreviates their Function Expressions without throwing in secret surprises that mess with their contexts. Fat arrow expressions become the special case, not the default. This mail suggested the difference between fat and thin arrow would confuse folks, but by removing thin arrow we remove the stepping stone between dynamically bound long form functions and hardbound short form functions and the necessary conceptual leap becomes more radical. 3) (This one was proposed by @fb55 on the es discuss list). Only employ lexical scoping as a fallback when no other this binding is suggested. In other words, this would take the value of the base reference in a method call, or the context passed with a call or apply, but would defer to lexical scoping when invoked as a standalone function. (Standalone functions might just be the only part of JavaScript this assignment that actually needs fixing anyway). Wrap Up Is the primary goal of arrow functions brevity? or a hard-lexical binding? If it’s the former (and even if it isn't, a lot of developers will perceive that it is) then we should be careful not to overload it with new or surprising behavior. Oh and follow @fat.

Dive into JavaScript to understand key differentiators between use of a Class and a Prototype - plus the impact each has on Lightning Web Components.

Get ready for high quality video on the screens of your life. Sun has entered into a multi-year agreement with On2 Technologies, to provide immersive media and content on your JavaFX applications. "The JavaFX runtime environment is designed from the ground up to support high fidelity media, empowering content authors to deliver media-rich content and applications across all the screens of your life. On2 shares Sun's vision of driving video convergence across desktops and mobile devices and we look forward to working with On2 to deliver this capability as part of the JavaFX family of products," said Rich Green, executive vice president, Software at Sun. RIAs written in JavaFX will be able to use the On2 video codecs from Fall 2008, at the same time as the 1.0 release of JavaFX desktop (an early access release is expected in July). We'll need to wait until Spring 2009 for JavaFX Mobile and JavaFX TV. The same high resolution video will run across all of these platforms. There's no doubt that JavaFX is in the spotlight for JavaONE 2008, and Sun seems intent on putting weight behind the technology so that it can rival the more established RIA offerings for Adobe and Microsoft. A new javafx.com site has been launched during the conference with tutorials, demos from the keynotes, downloads and getting started guides. Previously I've commented that the hype around JavaFX was too little, too late. The TrueMotion video codecs are a welcome and necessary addition to JavaFX. Perhaps the emphasis on JavaFX is worth it - after all, RIAs are the buzzword of the moment. Is this a sign of good things to come for JavaFX?

Did you know that you can join database tables into a Java Stream with Java 14's preview record feature? Find out how with Speedment Stream ORM.

Learn all about thread synchronization and concurrency in Java to get a better understanding of how to build robust, concurrent applications

A deep dive into the world of Java strings, with special attention to Java 8 string tutorials, plus a foray into Java string tutorials for Java 9 and one.

While "records" seem to be universally welcome, developers, especially fans of the object-oriented paradigm, should be careful when considering this new feature.

Check out this deep look into Java Records for declaring classes and see how it compares to Kotlin's Data Class and Scala's Case Class features.