g*****g
发帖数: 34805 | 1 是问桌面的.net程序没错，但您老一直鼓吹.Net的richness，html/js做不来，你好歹
也拿个像样的，TurboTax这种你所谓的dumb text的应用，html/js实现起来完全没有压
力的，你拿出来不是自己打脸吗？
Azure之于AWS就如Bing之于Google。AWS上Java写了一遍的东西，.NET抄一遍就算牛逼
了？你拿Azure出来捧.Net是无间道吗？
之于AutoCAD，官网上写得清清楚楚，内核C++写得，expose一个.NET interface，这就
变成.NET写得了？尼玛，Java有JNI，是不是Windows就是Java写得？
您老无知到这个份上，我老已经不知道怎么批驳好。我算是明白为啥MSFT 10年不举了。 |
|
|
t***a
发帖数: 416 | 3 那java应用里就不能有算法?
java里要是用到稍微像样的算法，就jni找c帮忙？ |
|
g*****g
发帖数: 34805 | 4 If you are going to use Android, you probably want to leverage Java as much
as possible. JNI is always available when you have to. |
|
g*****g
发帖数: 34805 | 5 还扯上了，连JNI跟RMI都不支持，java io的类库都藏了自己私货，还谈
兼容。JRockit 跑服务一直比Hotspot快，咋没见Sun告Weblogic？ |
|
z*******3
发帖数: 13709 | 6 对自己不熟悉的东西不要乱给“建议”
有个东西叫做jni |
|
w****k
发帖数: 6244 | 7 cpython 直接调用c不就可以，干嘛绕那么大弯用jython和jni |
|
z*******3
发帖数: 13709 | 8 宾狗
对于楼主来说，最简单的就是抛弃python上jvm
但是问题在于，这样做就丢掉了原来的代码
上jyphon可以最大程度复用代码
另外就是，jni只是一个小接口，这个有什么效率不效率的
一步的效率再慢能慢到哪里去，后面执行都是c的效率
前台执行完全是jvm的效率，这两个效率都明显有保证
有的是办法做优化，jvm的优化是几十年的积累
估计楼主用的就是web，上tomcat
效率明显高过各种乱七八糟的web server
这个效率也是n个人说过的例子了
/3 |
|
z*******3
发帖数: 13709 | 9 如果真有完美的解决方案，那项目就不会失败了
tech lead什么你也不用想得太牛
都是普通人，好的架构师跟恐龙一样稀少
慢慢换的意思是，你可以先把现有代码做一个wrapper
暴露接口给其它语言，比如java的jni就可以调用
然后再在这个基础之上，把所有后续的开发转到java上去
再慢慢对现有的代码做refactor
这是一个漫长而且痛苦的过程
现在delphi程序员是很难找，这是现状
没有办法 |
|
n***e
发帖数: 723 | 10 汗，jni和delphi，不知道哪个坑小点。。。。 |
|
z*******3
发帖数: 13709 | 11 至少可以从delphi这个坑爬出来
java不能说是坑，办法很多，市场上苦力也多
jni只是一个接口罢了，很小的一个部分，开销较大，尽量少用就是了
这是一条通向光明的路的入口，到达光明彼岸之前
黑暗的摸索少不了 |
|
g*****g
发帖数: 34805 | 12 JNI, RMI去了，core classes改了，还兼容性呢？真是无脑。 |
|
x****u
发帖数: 44466 | 13 安卓当然是java。
代码里面的C++也是被裁剪的非常彻底为JNI调用，离C的距离不远了。 |
|
S**********n
发帖数: 264 | 14 Hybrid structure is the way to go.
The power of C/C++ is on the lower level, including image processing.
However, C/C++ is too rigid and too expensive. In most companies, there are
differences between application developers and algorithm developers. The
product of the latter is libraries only. They even don't have any say on
threading models.
Except some qt freaks, there is limited areas where C/C++ is needed to do
the framework. Both java and .net are way better on this regard. Python
bi... 阅读全帖 |
|
w**z
发帖数: 8232 | 15 we tried to use imageMagic in Java via JNI. it has crazy memory leak. |
|
g*****g
发帖数: 34805 | 16 你要这么说，连JDK都是C的wrapper。但凡要IO访问都得吊C的JNI。 |
|
x****u
发帖数: 44466 | 17 C++难懂微软可不难懂，用COM搞列集比JNI整齐多了。
微软的失败是猪头决策者把好端端的项目搞成一坨屎。 |
|
x****u
发帖数: 44466 | 18 不一样，你用C搞一下jni就知道Java有多么恨C了。 |
|
d****i
发帖数: 4809 | 19 这个我也发现了，Python乍一看虽然不像Java那样语法上全部取自C，但是Python跟C的
接口比Java跟C的接口JNI友好方便些，所以Python还是在Native层更有生命力。
Jython |
|
N******K
发帖数: 10202 | 20 jni看了看 貌似很复杂 没看懂
Native |
|
z****e
发帖数: 54598 | 21 native会跟os绑定
垮平台feature被破坏
这个可是java当年最初的承诺之一
如果不能垮平台，java就不是java了
现在做script engine
对各种跨平台的script提供接口
可以了，jni就是要让他们麻烦
谁让你平台lockin的 |
|
d****i
发帖数: 4809 | 22 客观的说，相比于JNI接口，微软的.NET平台还是搞的比较好一点，听说.NET上调用
unmanaged native code也是很方便的，请熟悉微软平台的来说说是如何达到的。 |
|
b*******s
发帖数: 5216 | 23 这个人说得差不多，供您参考：
java的问题不是复杂，而是java语言本身不够复杂。比如这个接口的问题，哪怕增加个
default value，都能简化至少一半的API。
就因对世界的复杂性而言，任何语言都是一样的。
世界是复杂的，而java语言是简单的，所以才导致设计和库的复杂，这才是java复杂性
的根源。
比如对于上述的没有default value的问题，就冒出一个builder pattern来解决。
当实现一个目的有几条路可以走的时候，有的语言会选择增加一个语法糖来支持，有的
语言会选择通过API来支持，
而java更倾向于弄一套framework，或者design pattern来支持。
你可以说这是作为一个enterprise级语言的考虑，但我想说的是，如果任何时候都需要
这么做，那overhead太大了。
Java语言的基本思路就是，人力是廉价的，所以即使有些overhead，只要这种设计能通
过堆人力来解决，那么就这么做。
这种思路只适合于工人，不适合于像我这样的另一类人。
至于java的生态圈积累，其实java是另一种思路。java为了跨平台，更倾向于从底层开
始... 阅读全帖 |
|
|
z****e
发帖数: 54598 | 25 java现在在搞script engine
以后这些脚本跟jvm对接会更容易
本机上都可以了，不需要用web service
也不需要搞jni，就像groovy,scala那样
python什么也可以直接用java的类库了
所以还是java比较照顾同类
最后什么都还是得靠java来解决
jvm就是一巨脑，这个猴屁股以后只能慢慢去悲愤
为什么别人都要用jvm啊，啊啊啊啊啊啊，然后崩溃了 |
|
z****e
发帖数: 54598 | 26 corba -> rmi -> web service
jni -> script engine
这都是一个演绎进化的过程 |
|
z****e
发帖数: 54598 | 27 那就vert.x了
其实有很多种方法
比如楼上说的用web service以及各种wrapper
或者用esb这些，不过感觉重了点
vert.x自带一个小型的event bus
对语言实现本身绝缘，所以用这个可以快速开发出一个东东出来
然后主体实现语言你可以自选
还有一种比较糟糕的实现就是自己用python去call jvm
或者是用java的jni去call python，这两个都不推荐
最后一个选择就是等jvm上的script engine
不过这个要等很久，算了，干活要紧
JAVA |
|
d********g
发帖数: 10550 | 28 知道你要喷我特地注明了是“态度”不是实现，你和goodbug不早说了一旦碰了C就影响
跨平台，这就是“态度”问题，不是说不能做
JNI你自己早些时候早把它喷出翔了，现在为了喷我又来捧
或者“不推荐”比“不支持”更贴切，这样可以吧 |
|
z****e
发帖数: 54598 | 29 你说的只是兼容性的问题
它说的是将来，你说的是如何兼容现有代码
这个很正常，python就提供了一个接口给c
java也提供了jni给c++，这种兼容性处理一下就好了 |
|
z****e
发帖数: 54598 | 30 没有强推啊
对js保持兼容啊
dart可以编译成js啊
两种方式啊
这两种方式一种是用来适应丑陋的现实，which is javascript
另外一种方式是用来推广自身的os，which is chromeos
这一招很高明啊
.net如果一开始就兼容java，同时在java上增加windows的类库
那结果不好说呢，其实ibm就是这么做的
.net主要是m$修改了java，尤其是修改了jni这些java标准库
所以才闹翻，ibm就没改，但是ibm的东西里面私货很多
所以后来ibm通过java赚了好多钱 |
|
r**********g
发帖数: 22734 | 31 呃，蜥蜴你说java不用管内存是不对滴。我搞hadoop还自己搞了java实现的swap space
。java 的内存不仔细优化照样不知道怎么死的。除非你就是写写business logic。其
实真要碰到memory hog的大程序，还是得上C++。好几次都是彻底没辙上了JNI。
你看看Hadoop，HDFS的库是不是还有一陀C++在里面丫 |
|
z****e
发帖数: 54598 | 32 有Sun搞你们MS, Oracle告Google，
你这个真是不像话
绝对的颠倒黑白
m$被告是因为jni被改了
只要名字挂在java下面的东西
就必需遵守规则，否则游戏没法玩
跨平台是最早的特性之一
如果没有跨平台，java早不知道去哪里乐去了
因为跨平台，省程序猿多少麻烦
最后法庭判决也是倾向于sun的，m$不得不自己搞一个.net去
google被告也是类似，但是最后法庭判决则倾向于google
因为google一开始就没说自己是java，而是android
oracle指责google的java也就是android跟其他jvm不兼容
这也无可厚非，android的确不兼容，难道不是么？
jrockit上的jar剥下来放到hotspot上一样跑
dalvik上的apk剥下来放到其他jvm上能跑么？
说到底java能走到今天，也是因为java对于各种破坏行为采取的态度
要不是坚决搞掉这些害群之马，今天会有无数个版本的固定在无数个平台上的java
这种现实是无论如何没有任何一个程序员愿意看到的
哪有办法开发编译一次，生产再搞一次，测试都测试不过来 |
|
|
g*****g
发帖数: 34805 | 34 If you could front the java API with a rest service, it's better that way.
Otherwise, you can try JNI. |
|
I*****n
发帖数: 90 | 35 多谢楼上二位指路，我去看下ikvm 和jni.
二位元宵快乐！ |
|
|
|
k**********g
发帖数: 989 | 38
Any code needing numerical and signal processing would still need to write
in C or C++ or OpenCL via JNI.
For now, Java and Microsoft MSIL JIT still do not generate SIMD code
directly. Only Mono has SIMD support.
SIMD is significant for heavy numerical processing because it processes e.g.
4 - 16 values at once. GPU is even more powerful. These two techniques will
continue to scale up, in part closing the Moore's Law gap.
High-level libraries e.g. graphics, mathematical, financial, video
process... 阅读全帖 |
|
z****e
发帖数: 54598 | 39 java在c++那个年代，主要对手是c++，这是二十年前
然后j2ee发展出来之后，对手换成了c#和.net，这是十年前
现在web时代，真正的利益对象是python,ruby这些
现在主流根本不是什么c++，c++压根到不了这个层次
停留在简单的jni上，20年前的技术
c#发展出了一些东东，比如f#这些，然后java社区在抄这些东西
clojure和rxjava最早都是.net上的原型，现在抄过来
对于ruby这些脚本来说，现在要做的是接轨这些脚本
直接搬运这些脚本类库到jvm上，同时也让这些脚本能够用java的类库
vert.x就是多语言的，互相接轨，互通有无
然后还有通信那帮人用erlang做的东西，所有人都在汇集到一片海里去
要做什么，能做什么，完全都是个人意愿
总结：我现在要学也不学c++，有的是东西可以学，爆炸式增长 |
|
n****1
发帖数: 1136 | 40 这个我才发现, 震惊了.不过还好是library, 不是language primitive. 莫非要程序员
手动避免死锁?
可能像java里面的jni允许手动管理内存一样, 不想把事情做绝,但我感觉后患无穷. |
|
g*****n
发帖数: 420 | 41
静态链接只是link static的.a文件又不是链接动态共享库dylib,你搞错了吧?静态链接
的只是Net Framework的class.你确定你明白你说的东西吗?
Xcode静态链接的时候也不会去把dylib打包进app,Android NDK也不会的吧libz.dylib
打包进去的,只有staic lib的.a文件才会被link的.dylib仍然是共享的被调用的.
你看过反编译的DotNet Framework代码就清楚,DotNetframework也只是通过PInvoke去
调用共享dll的api实现平台api调用,不会把dll也打包的.
Java的runtime也是一样的通过jni去调用C的各种dylib库而已 |
|
n****1
发帖数: 1136 | 42 PaaS往往限制了能使用的语言和类库，所以连跑个JNI或python C module都可能被禁。
IaaS就是连内核都是单独运行。
docker能做到的就是跑任何用户态程序，无论语言无论类库配置文件。除非应用需要设
计内核编程，或者要利用某个特殊内核功能而公共内核没有， 否则docker都能游刃有
余。
applications |
|
z****e
发帖数: 54598 | 43 java有版权，而且版权很凶，非常严格，要求所有jvm必需能够执行jar文件
还有jni这些，google搞了一个android，编译成apk，which就不是jar
还好没有叫自己是java，否则被告死死的，现在主要是android上的一些api
名字还是java.,javax.这些，以前sun跟google保证过，说这个你用，没关系
不告你，但是后来sun被oracle吞并了，oracle现在就说这个名字你不能这样用
要改成android,androidx.这些，这个是不是有道理，问jury去了
sun其实后期瞎搞了很多，sun被oracle吞并之后，什么mysql都很糟糕了
sun被吞并其实不是什么好事 |
|
x****u
发帖数: 44466 | 44 和VM没关系。
C++写个jni模块就不行，python就可以。还是语言的特性更重要。 |
|
z****e
发帖数: 54598 | 45 c话还没说完，后半句是这样的
麻痹的，这个地方土地贫瘠，已经没啥可以让孩子们继续吃的了
你们赶紧走，我老了，走不动了，只好留下
等开源核弹来了，我也退休了，不搞啥狗屁软件了
你们不一样，你们还年轻，你们还有将来，不要在这里等着被开源炸死
话说人家问你一个php和java怎么互相call
你居然回答说用jni
你有没有觉得自己凹凸得有些过份了？
甚至比不上20年前那些搞corba的
JavaScript |
|
Q**g
发帖数: 183 | 46 关键是layering。只要UI部分有效的剥离开了，底层得东西用native code写更容易复
用。Java app 可以用JNI调native库。反过来就不好玩了。 |
|
g*****g
发帖数: 34805 | 47 别扯蛋了，ConcurrentHashMap是个纯的Java实现。当然你要追究底下都用compare&
swap. 作为虚拟机，不调JNI连IO都做不了。 |
|
|
D***n
发帖数: 6804 | 49 谢谢你的提示，原来Java搞了个JNI出来抄近路，我对Java Concurrency实现机制有所
了解了。 |
|
|
