z****e
发帖数: 54598 | 1 有一个项目叫做javafx ports
http://javafxports.org/page/home
idea也很简单，因为java已经实现了电脑上的跨平台
javafx是java的一部分，自然也实现了电脑上的跨平台
以及native compiling，可以直接编译成os(win,mac,linux)相关的机器码
那么现在这个项目要做的就是
把javafx给export到android和ios上去
ios靠的是robovm，很早以前就在做的一个通过java写ios上app的东西
android的话，因为dalvik本身支持jar的依赖
所以只要额外再打个包就好了
核心那个逻辑jar不用变，那个jar多半是javafx写的
客户端跨平台是一个美好的梦想
构想很好，操作起来，异常恶心
比如最简单的io，mobile和pc上的输入是不一样的，输出当然也不一样
各种屏幕，还有一些常用的第三方类库，比如卖广告的admob
admob不支持在电脑app上卖广告
所以到最后你还不如不跨平台
但是不管怎样，这种东西有总比没有好，有选择总是好滴 |
p**r
发帖数: 5853 | 2 所有的跨平台都是纸老虎，
就像ios/andriod的各路第三方开发工具，
你自己玩玩可以，
真要放到现实中用，
还是得乖乖的object c/swift开发ios，
然后java开发andriod，
不然就是出来2个四不像。 |
Q**g
发帖数: 183 | 3 关键是layering。只要UI部分有效的剥离开了，底层得东西用native code写更容易复
用。Java app 可以用JNI调native库。反过来就不好玩了。
【在 z****e 的大作中提到】
: 有一个项目叫做javafx ports
: http://javafxports.org/page/home
: idea也很简单，因为java已经实现了电脑上的跨平台
: javafx是java的一部分，自然也实现了电脑上的跨平台
: 以及native compiling，可以直接编译成os(win,mac,linux)相关的机器码
: 那么现在这个项目要做的就是
: 把javafx给export到android和ios上去
: ios靠的是robovm，很早以前就在做的一个通过java写ios上app的东西
: android的话，因为dalvik本身支持jar的依赖
: 所以只要额外再打个包就好了
|
z****e
发帖数: 54598 | 4 他们这样做的好处就是核心的逻辑不用每次都重新编译
jar可以共通，export到android上去的话，只要重新打成apk就行了
如果export到ios上去，直接转译成native code就是了
虽然要想os本地化，还是需要额外打包，但是核心逻辑就是那个jar
可能会省点事，如果mvc切割得好的话，model部分应该能够重用
【在 Q**g 的大作中提到】
: 关键是layering。只要UI部分有效的剥离开了，底层得东西用native code写更容易复
: 用。Java app 可以用JNI调native库。反过来就不好玩了。
|
g****t
发帖数: 31659 | 5 跨平台的意思就是。一套软件在不同硬件下表现一样。
那么终端用户就感受不到不同硬件的区别。
那么不同硬件就没有高下差异之分。
那么这就把硬件公司的价值杀到零了。
这当今的世界这完全是不可能的。
Apple,SS,联想，华为，小米,LG都是硬件公司。
和这些硬件公司比起来goog, fb之类的都不算啥。
所以跨平台的软件构思先天上就是扯淡。
完全不可能。
5年前我就在EE说facebook走html 5是死路一条。
但是，反过来说。
如何跨平台并且不屏蔽硬件价值？
这就是高科技了。类似于20年前Sun提出Java.
【在 z****e 的大作中提到】
: 有一个项目叫做javafx ports
: http://javafxports.org/page/home
: idea也很简单，因为java已经实现了电脑上的跨平台
: javafx是java的一部分，自然也实现了电脑上的跨平台
: 以及native compiling，可以直接编译成os(win,mac,linux)相关的机器码
: 那么现在这个项目要做的就是
: 把javafx给export到android和ios上去
: ios靠的是robovm，很早以前就在做的一个通过java写ios上app的东西
: android的话，因为dalvik本身支持jar的依赖
: 所以只要额外再打个包就好了
|
Q**g
发帖数: 183 | 6 看了下他们的主页，还在很早期阶段的样子。很难吸引主流app吧。
【在 z****e 的大作中提到】
: 他们这样做的好处就是核心的逻辑不用每次都重新编译
: jar可以共通，export到android上去的话，只要重新打成apk就行了
: 如果export到ios上去，直接转译成native code就是了
: 虽然要想os本地化，还是需要额外打包，但是核心逻辑就是那个jar
: 可能会省点事，如果mvc切割得好的话，model部分应该能够重用
|
a*****e
发帖数: 1700 | 7 狗狗最近出的 inbox app 就跨平台做的
http://nfil.es/w/UH9ep0/
为了跨平台快速开发，Inbox 的 data model 和 application logic 用 Java 写，然
后用 GWT 翻译成 Javascript 用于 Web app，用 J2ObjC 翻译成 Objective C 用于
iOS app。
LOL
【在 p**r 的大作中提到】
: 所有的跨平台都是纸老虎，
: 就像ios/andriod的各路第三方开发工具，
: 你自己玩玩可以，
: 真要放到现实中用，
: 还是得乖乖的object c/swift开发ios，
: 然后java开发andriod，
: 不然就是出来2个四不像。
|
w***g
发帖数: 5958 | 8 所有的跨平台都是事后诸葛亮。一个软件是可以做到跨现有的平台的，但是往往无法跨
未来的平台。本身跨平台方案的出现就表示人们已经理解了现有平台之间的共同点，或
者说现有的平台在技术上已经converge了。这种converge发展到最后会导致现有的各个
平台中只有一个胜出，最终导致跨平台方案失去意义。比如以前写java可以跨windows,
linux, solaris, freebsd啥的，现在solaris死了，freebsd没有成长起来，windows
也快死了，最后服务器就只剩下Linux一个。再说CPU架构，现在几乎所有的机器都是
x86，Java的big endian在很大程度上就只是一个负担了。
新的平台的出现往往是要打破现有平台的框架的。比如android啥的。本来android除了
核以外就都是java的，不然怎么反而出现了跨平台的问题呢？以后肯定还会出来非x86
的牛B架构，比如说neural computing(瞎说的)，如果这种架构真是牛B到能秒杀x86，
那么肯定和过去出现过的各种架构都很不一样，java跨不到这种新平台上的可能性会更
大。
我记不起来啥用JavaFX写的桌面程序，可能在enterprise market有吧。但是android和
iOS都是consumer market。我看不到javaFX在这上面有啥出路。
【在 z****e 的大作中提到】
: 有一个项目叫做javafx ports
: http://javafxports.org/page/home
: idea也很简单，因为java已经实现了电脑上的跨平台
: javafx是java的一部分，自然也实现了电脑上的跨平台
: 以及native compiling，可以直接编译成os(win,mac,linux)相关的机器码
: 那么现在这个项目要做的就是
: 把javafx给export到android和ios上去
: ios靠的是robovm，很早以前就在做的一个通过java写ios上app的东西
: android的话，因为dalvik本身支持jar的依赖
: 所以只要额外再打个包就好了
|
Q**g
发帖数: 183 | 9 对这种大量依赖Web后端的app还好。不是普遍适用的。
前两年俺们公司跟风html 5，内部出了个平台然后要各个产品组转向html5。结果被
performance和兼容性搞死。得不偿失。发了一个版本就放弃了。web平台组解散。
Features用各平台native重写。
同期放弃html5的公司还有facebook, linkedin 等等
【在 a*****e 的大作中提到】
: 狗狗最近出的 inbox app 就跨平台做的
: http://nfil.es/w/UH9ep0/
: 为了跨平台快速开发，Inbox 的 data model 和 application logic 用 Java 写，然
: 后用 GWT 翻译成 Javascript 用于 Web app，用 J2ObjC 翻译成 Objective C 用于
: iOS app。
: LOL
|
Q**g
发帖数: 183 | 10 跨平台也不是非黑即白的。一个复杂的产品可以有相当大部分的跨平台的核心，和平台
相关的前端。跨平台的成功项目多了去了。比如openssl, webkit, sqlite...
windows,
windows
x86
【在 w***g 的大作中提到】
: 所有的跨平台都是事后诸葛亮。一个软件是可以做到跨现有的平台的，但是往往无法跨
: 未来的平台。本身跨平台方案的出现就表示人们已经理解了现有平台之间的共同点，或
: 者说现有的平台在技术上已经converge了。这种converge发展到最后会导致现有的各个
: 平台中只有一个胜出，最终导致跨平台方案失去意义。比如以前写java可以跨windows,
: linux, solaris, freebsd啥的，现在solaris死了，freebsd没有成长起来，windows
: 也快死了，最后服务器就只剩下Linux一个。再说CPU架构，现在几乎所有的机器都是
: x86，Java的big endian在很大程度上就只是一个负担了。
: 新的平台的出现往往是要打破现有平台的框架的。比如android啥的。本来android除了
: 核以外就都是java的，不然怎么反而出现了跨平台的问题呢？以后肯定还会出来非x86
: 的牛B架构，比如说neural computing(瞎说的)，如果这种架构真是牛B到能秒杀x86，
|
|
|
h******b
发帖数: 6055 | 11 跨平台不代表真正一套代码两个平台，而是尽可能共用library增加code reuse。能八
成代码共享就已经很强大了。
国内是cocos2dx就是很好的例子。 连刀塔传奇这样畅销榜顶尖级别的游戏也可以完成。
建议去看看cocos2dx的showcase，大把顶级畅销游戏。
游戏都能跨平台，其他的app就更简单了。 |
Q**g
发帖数: 183 | 12 Exactly
成。
【在 h******b 的大作中提到】
: 跨平台不代表真正一套代码两个平台，而是尽可能共用library增加code reuse。能八
: 成代码共享就已经很强大了。
: 国内是cocos2dx就是很好的例子。 连刀塔传奇这样畅销榜顶尖级别的游戏也可以完成。
: 建议去看看cocos2dx的showcase，大把顶级畅销游戏。
: 游戏都能跨平台，其他的app就更简单了。
|
z****e
发帖数: 54598 | 13 那当然，javafx刚成熟没多久
1.7u45才正式纳入java，之前都是独立的一个项目
desktop上跨平台刚实现没多久，swing不算的话
然后javafx to android和javafx to ios两个也都比较新
to android的项目作者就是做那个项目的作者
这几个里面，to ios也就是robovm应该是成熟度相对比较高
而且应用比较广的一个项目，有不少app就是用robovm做的
可以在他们的主页上看到，robovm打算创业了，接近成功了
不少公司掏钱买他们的服务，每次去看他们的网页，都有新进展
http://www.robovm.com/
【在 Q**g 的大作中提到】
: 看了下他们的主页，还在很早期阶段的样子。很难吸引主流app吧。
|
c***k
发帖数: 1589 | 14 游戏跨平台容易，因为都是c或者c++
不依赖于太多的平台UI framework
大型软件如office跨平台也有可能，因UI不是最大的组件。小app搞跨平台就是zuo
成。
【在 h******b 的大作中提到】
: 跨平台不代表真正一套代码两个平台，而是尽可能共用library增加code reuse。能八
: 成代码共享就已经很强大了。
: 国内是cocos2dx就是很好的例子。 连刀塔传奇这样畅销榜顶尖级别的游戏也可以完成。
: 建议去看看cocos2dx的showcase，大把顶级畅销游戏。
: 游戏都能跨平台，其他的app就更简单了。
|
h******b
发帖数: 6055 | 15 小app跨平台一样可以搞phonegap/cordova/ionic。
http://showcase.ionicframework.com
小app本来靠的就是创意，不是技术。 跨平台最快最猛出成果。 不纠结缺少
platform specific功能。
【在 c***k 的大作中提到】
: 游戏跨平台容易，因为都是c或者c++
: 不依赖于太多的平台UI framework
: 大型软件如office跨平台也有可能，因UI不是最大的组件。小app搞跨平台就是zuo
:
: 成。
|
z****e
发帖数: 54598 | 16 javafx刚弄出来没多久
你当然记不起来
你能记得起来的是swing
javafx能够跨pc&mac平台，这个是一个优势
java以前的gui部分是最弱的，主要是sun比较死板
像native compiling这种就没有去做，死活不干，要求所有的os先预装jvm
那谁干，m$什么都不配合，apple以前还有自己的jdk&jvm
标准倒是比较统一，但是impl其实各写各的
ibm, apple, bea, red hat, apache都有自己的java版本
现在都干掉了，就留下hotspot和openjdk两个版本
openjdk就包含有以前jrockit, r9, iced tea, apple java等的代码
现在pc在走下坡路，主要目标平台是android和ios
javafx其实官方已经有能在android和ios上运行的版本了
但是好像官方没有这个想法去弄，因为这可能涉及到替换jvm的问题
要在ios上弄一个jvm或者把android的dalvik给换掉，变成正经的jvm
那apple和google肯定不配合，那现在只能说把jar直接编译成这两个平台上的native啊
什么的
去执行，那这种算不算是跨平台，那就看各人自己定义了
其实编译一次，到处运行是最理想的，可惜理想总是那么遥远
windows,
windows
x86
【在 w***g 的大作中提到】
: 所有的跨平台都是事后诸葛亮。一个软件是可以做到跨现有的平台的，但是往往无法跨
: 未来的平台。本身跨平台方案的出现就表示人们已经理解了现有平台之间的共同点，或
: 者说现有的平台在技术上已经converge了。这种converge发展到最后会导致现有的各个
: 平台中只有一个胜出，最终导致跨平台方案失去意义。比如以前写java可以跨windows,
: linux, solaris, freebsd啥的，现在solaris死了，freebsd没有成长起来，windows
: 也快死了，最后服务器就只剩下Linux一个。再说CPU架构，现在几乎所有的机器都是
: x86，Java的big endian在很大程度上就只是一个负担了。
: 新的平台的出现往往是要打破现有平台的框架的。比如android啥的。本来android除了
: 核以外就都是java的，不然怎么反而出现了跨平台的问题呢？以后肯定还会出来非x86
: 的牛B架构，比如说neural computing(瞎说的)，如果这种架构真是牛B到能秒杀x86，
|
z****e
发帖数: 54598 | 17 跨平台的意思是不需要重新编译的代码共享
c类代码对于不同os需要重新编译
这里面有啥问题，那就很难说了
就像python的类库，不少是c写的，我在mac上重新编译出了不少问题
code reuse这个其实copy paste是最低级的
现在做到的是jar能够直接拿来再打个包就用
这连code reuse都省了，直接终端产品reuse了，虽然这个还是半吊子的跨平台
成。
【在 h******b 的大作中提到】
: 跨平台不代表真正一套代码两个平台，而是尽可能共用library增加code reuse。能八
: 成代码共享就已经很强大了。
: 国内是cocos2dx就是很好的例子。 连刀塔传奇这样畅销榜顶尖级别的游戏也可以完成。
: 建议去看看cocos2dx的showcase，大把顶级畅销游戏。
: 游戏都能跨平台，其他的app就更简单了。
|
z****e
发帖数: 54598 | 18 小app与其去折腾跨平台，其实还不如就用平台的ide去写
没啥难的，现在swift什么都很容易写了
以前android上之所以还在用c之类的
一个很重要原因是legacy code是c写的
这个legacy code说的是以前的游戏
cocoa2d现在用swift什么调一点都不难
而且cocoa2d有的是各种乱七八糟语言版本
包括java，其实就一个语言接口而已了
跨平台并没有想象的那么快，经常会遇到各种狗血的问题
快只是跨平台的一个初衷，但是实现起来往往做不到
【在 h******b 的大作中提到】
: 小app跨平台一样可以搞phonegap/cordova/ionic。
: http://showcase.ionicframework.com
: 小app本来靠的就是创意，不是技术。 跨平台最快最猛出成果。 不纠结缺少
: platform specific功能。
|
w***g
发帖数: 5958 | 19 啥叫刚弄出来不久。都好几年你了。 JavaFX vs silverlight vs flash都是老话题了。
【在 z****e 的大作中提到】
: javafx刚弄出来没多久
: 你当然记不起来
: 你能记得起来的是swing
: javafx能够跨pc&mac平台，这个是一个优势
: java以前的gui部分是最弱的，主要是sun比较死板
: 像native compiling这种就没有去做，死活不干，要求所有的os先预装jvm
: 那谁干，m$什么都不配合，apple以前还有自己的jdk&jvm
: 标准倒是比较统一，但是impl其实各写各的
: ibm, apple, bea, red hat, apache都有自己的java版本
: 现在都干掉了，就留下hotspot和openjdk两个版本
|
z****e
发帖数: 54598 | 20 1.0版本吧？那个只是蓝图
2.0之后重做了，2.0到mac版到linux版
也是前两年才搞出来的
然后真正集成到java里面去是1.7u45之后的事
1.7u45能多早？
【在 w***g 的大作中提到】
: 啥叫刚弄出来不久。都好几年你了。 JavaFX vs silverlight vs flash都是老话题了。
|
|
|
Q**g
发帖数: 183 | 21 这个跨平台的定义感觉狭窄了一些，也过于理想化了。个人认为。engineering is
full of tade-offs。真要做到了无需重编译就跨平台了很可能别的方面又会有牺牲。
未必就是你想要的。
不管跨平台怎么定义，用最少的开发量支持最多的平台的需求是实实在在的。是追求理
想的无重编译写一次到处运行但是受限于现有的开发工具，还是有效利用已知的实践检
验过的技术实现软件复用，你的选择。
话又说会来。有追求才有进步。祝javafxports那帮人成功。
【在 z****e 的大作中提到】
: 跨平台的意思是不需要重新编译的代码共享
: c类代码对于不同os需要重新编译
: 这里面有啥问题，那就很难说了
: 就像python的类库，不少是c写的，我在mac上重新编译出了不少问题
: code reuse这个其实copy paste是最低级的
: 现在做到的是jar能够直接拿来再打个包就用
: 这连code reuse都省了，直接终端产品reuse了，虽然这个还是半吊子的跨平台
:
: 成。
|
T*******x
发帖数: 8565 | 22 有道理。
windows,
windows
x86
【在 w***g 的大作中提到】
: 所有的跨平台都是事后诸葛亮。一个软件是可以做到跨现有的平台的，但是往往无法跨
: 未来的平台。本身跨平台方案的出现就表示人们已经理解了现有平台之间的共同点，或
: 者说现有的平台在技术上已经converge了。这种converge发展到最后会导致现有的各个
: 平台中只有一个胜出，最终导致跨平台方案失去意义。比如以前写java可以跨windows,
: linux, solaris, freebsd啥的，现在solaris死了，freebsd没有成长起来，windows
: 也快死了，最后服务器就只剩下Linux一个。再说CPU架构，现在几乎所有的机器都是
: x86，Java的big endian在很大程度上就只是一个负担了。
: 新的平台的出现往往是要打破现有平台的框架的。比如android啥的。本来android除了
: 核以外就都是java的，不然怎么反而出现了跨平台的问题呢？以后肯定还会出来非x86
: 的牛B架构，比如说neural computing(瞎说的)，如果这种架构真是牛B到能秒杀x86，
|
r***y
发帖数: 4379 | 23 robovm 对反感果子的一切又不得不做 ios app 的人是个好东西
【在 z****e 的大作中提到】
: 有一个项目叫做javafx ports
: http://javafxports.org/page/home
: idea也很简单，因为java已经实现了电脑上的跨平台
: javafx是java的一部分，自然也实现了电脑上的跨平台
: 以及native compiling，可以直接编译成os(win,mac,linux)相关的机器码
: 那么现在这个项目要做的就是
: 把javafx给export到android和ios上去
: ios靠的是robovm，很早以前就在做的一个通过java写ios上app的东西
: android的话，因为dalvik本身支持jar的依赖
: 所以只要额外再打个包就好了
|
z****e
发帖数: 54598 | 24 开发测试还是需要xcode
【在 r***y 的大作中提到】
: robovm 对反感果子的一切又不得不做 ios app 的人是个好东西
|
r***y
发帖数: 4379 | 25 是呀, 所以果子灰常evil...
至少码可以不用果子的了
【在 z****e 的大作中提到】
: 开发测试还是需要xcode
|
